Models that know about each other, and have a self

Three features sharing one idea: a model here started from nothing every
conversation and had no notion that anything else existed.

THE ROSTER. `chat.roster_block` builds one line per model this *person* can
reach -- through `permissions.models_visible_to`, never the table -- and
`{{model_roster}}` carries it, gated on the `friend` family for the reason the
memories block is gated on `memory`: a list of peers a model cannot talk to is
context spent on nothing, and one checkbox is then the whole switch. New
`Model.notes` column, a column and not a `capabilities_json` key for the reason
`context_length` and `reasoning_efforts` both carry.

ASKING A FRIEND. A second entry point in `services/subagent.py` rather than a
second module, so one place still owns the bounds and the lifecycle. `_create_
child` takes the friend's (model_id, connection_id) *pair*, because Model is
unique on both and an id alone does not say which endpoint. Three things differ
from a helper: the effort is the friend's own default and never the parent's (the
1.3.0 bug by another door -- the vocabularies differ and a level a model does not
take raises inside its chat template), the chat is ordinary even when the asker's
is an agent chat, and `scope_json["role"]` marks it so `core.friend` speaks
instead of `core.subagent`. `friend` joins the unattended withdrawal set: a
friend that could ask a friend is the same unbounded fan-out in politer clothes.
Budget, concurrency and quota are shared with helpers, so one reply cannot spend
the allowance twice.

PERSONALITY. One table, two roles, `owner_id IS NULL` the discriminator: the
model's own persona, and its read of one person. Keyed on the model's *text* id
with no foreign key, because "Test & refresh" deletes a model the endpoint has
stopped listing and a personality must not be collateral. `PersonaRevision`
copies SkillRevision, and so does the argument: the safety story for a model
rewriting itself is a record and a way back, not a gate. The reflection is shown
to the person it is about, in their own settings, which is the whole of why
keeping one is acceptable. `persona` is withdrawn from any unattended chat --
a helper's task, a friend's question and a schedule's instruction are all words
nobody watched being written.

Two bugs found while reading for this, both silent:

`review_model_id` stored a `Model` primary key, so a refresh taken while an
endpoint was not listing that model unset the administrator's choice -- and
`_reviewer` then fell back to the chat's own model, so pictures were judged by
a model nobody chose. Now the text id, with the primary key still accepted.

`_messages_after` used a bare `>` on `created_at`, so a row sharing the edited
turn's microsecond survived a rewind -- and `_send` writes a user turn and its
placeholder back to back, which is exactly that tie. Deliberately NOT
`thread_tail`'s `(created_at, id)` tiebreak: ids are random UUIDs, so that
settles a tie by coin toss. A tie now reads as "later", which is the safe
direction for an operation whose purpose is to discard what follows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/lembas/api/chats.py

@@ -1485,11 +1485,34 @@ def _thread_context(db: DBSession, chat: Chat, user: User) -> dict:
 
 
 def _messages_after(db: DBSession, message: Message) -> list[Message]:
+    """Everything later in this chat than one message.
+
+    Everything *tied* with it counts as later, which is the part worth
+    explaining. Under a bare `>` a row sharing this one's microsecond is never
+    after it and survives a rewind -- an orphan below the turn being edited, in
+    the transcript and in every later request. `_send` writes a user turn and its
+    assistant placeholder back to back, so that pair is exactly what ties, and it
+    is exactly what a rewind of that turn has to take.
+
+    ⚠ Deliberately **not** `thread_tail`'s `(created_at, id)` tiebreak, which is
+    right there and wrong here. That one needs any stable total order, because it
+    is a polling cursor. This one has to agree with the order somebody is looking
+    at, and `Message.id` is a random UUID -- so comparing ids would resolve a tie
+    by coin toss, keeping some later rows and deleting some earlier ones. Reading
+    an ambiguous tie as "later" instead is the safe direction for an operation
+    whose whole purpose is to discard what follows: one extra row deleted is what
+    the reader asked for, while one row left behind corrupts every request after
+    it.
+    """
     return list(
         db.scalars(
             select(Message)
-            .where(Message.chat_id == message.chat_id, Message.created_at > message.created_at)
-            .order_by(Message.created_at)
+            .where(
+                Message.chat_id == message.chat_id,
+                Message.created_at >= message.created_at,
+                Message.id != message.id,
+            )
+            .order_by(Message.created_at, Message.id)
         )
     )