v0.11.6

A subagent's session is not its parent's

Codex forks a subagent's rollout from the session that started it, and the file's first
session_meta is that fork record: session_id there is the parent's id, and the file's own
is in id — the same UUID that ends the filename. The list read session_id first, so every
subagent was reported as its parent, and several files came back under one sessionId.

Measured across every rollout on a real install: on the seven subagent files id equals the
UUID in the filename and session_id equals the parent's, while the nine ordinary ones carry
the same value in both fields.

An id is what everything else names a session by, so this was not only a listing detail — the
reader opened the wrong session for a duplicate row, and /sessions/<id> had nothing to choose
between them. A subagent is listed under its own id now; a forked meta that carries no id
falls back to the filename, and only a file with no metadata row at all uses a salvaged id.

The rows that would not go away

Switching the page's source filter to claude left codex rows behind — 48 rows where 27 were
expected, with those same shared ids.

The list is patched by sessionId rather than rebuilt, so a poll updates text in place instead
of throwing away what you are reading. The index that patch uses holds one node per id, and with
two rows sharing an id the earlier node was in neither the next render's rows nor the sweep that
clears what is no longer listed: nothing ever removed it, and it outlived every filter that
should have dropped it.

A repeated id now drops the earlier node as the index is built. The duplicates themselves are
gone with the fix above; this is what kept them on screen for as long as they lasted.

Full changelog: v0.11.5...v0.11.6