Offer a session once when two project folders hold it, and never crash on a repeat

Resuming a Claude Code session from a different working directory makes the
CLI write a second transcript with the same id under that directory's
project folder. This machine has one: 160 KB under `-home-bob-repos-tdep-survey`
and a 614-byte stub under `-home-bob-repos-tdep`. Everything downstream
addresses a session by id -- `--resume` takes it, the delete glob resolves
it, the in-flight registry is keyed on it -- so two rows sharing an id are
two rows no operation can tell apart, and the phone keys its list on it, so
scrolling to them closed the app on Compose's duplicate-key throw.

The listing now keeps the copy with the most in it. Size rather than
recency, because the stub is often the newer of the two, and picking it
describes the session by the wrong size, the wrong cwd and the wrong title.
Deleting removes every copy rather than stopping at the first, which had
left the row to come back on the next listing after a delete that reported
success.

The phone's half is `uniqueItems`: every list keyed on a server-chosen id
goes through it, since none of them could rule the repeat out locally and a
data problem must not be able to close the app. Verified both ways against
the real duplicate -- the unguarded build reproduces the reported stack on
the same id, the guarded one scrolls the whole list.

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

AGENTS.md

@@ -255,6 +255,20 @@ first if a remote spawn ever mangles an argument.
   be there to import again" is exactly the one the switch makes false. The
   server deletes the machine's copy *first*, so a machine it cannot reach
   leaves the session where it was instead of half-deleted.
+- **One Claude Code session id can name two files, and the listing offers
+  it once.** Resuming a session from a different working directory makes
+  the CLI write a second transcript with the same id under that
+  directory's project folder -- an ordinary state of a machine, not
+  corruption. Everything downstream addresses a session by id (`--resume`,
+  the delete glob, the in-flight registry) and the phone keyed its list on
+  it, so two rows sharing one *closed the app* on a Compose duplicate-key
+  throw. `parse_listing` keeps the copy with the most lines, because the
+  other is usually a few-hundred-byte stub and is often the *newer* of the
+  two -- so recency is the wrong key. Deleting removes every copy rather
+  than the first, or the row came back after a delete that reported
+  success. The phone's half is `uniqueItems`, which every list keyed on a
+  server-chosen id goes through: a repeat there must never be able to
+  close the app, whatever produced it.
 - **A markdown table wraps its cells and never cuts one off.** The
   renderer's own defaults draw every cell at one line with an ellipsis,
   which on a phone loses most of a table -- and an elided cell looks