feat(sessions): fork a session — the what-if branch - #67

The largest designed-but-unbuilt piece of the triad. §313: "resume a copy from
any point, leaving the original intact — the what-if-I'd-told-it-to-do-X-instead
branch." Fork-from-END, as §411 settles the scoping: per-turn fork needs a
transcript picker, which is separate work.

WHICH EVENTS TRAVEL is the entire design, and the answer is not "all of them":

  user / agent / assistant   YES — this is the conversation being forked
  title                      YES, then overridden, so the fork is not a second
                             row with an identical name
  end                        NO  — that is the ORIGINAL's terminal state. Copying
                             it renders a live fork as `done` while you type
  label                      NO  — lifecycle and pinning are the original's. A
                             fork of an archived session must arrive visible, and
                             must not silently take a second pin

The copy records `forkedFrom` in its meta — §4 provenance, and what a later
branch-graph draws from. The key is written ONLY on a fork, so every existing
session file stays byte-identical and an older build reading a forked session
simply does not know it was forked rather than failing to read it.

A fork IS a resume, into a copy, so the handler calls resumeSession() on the new
id rather than duplicating the replay, the budget planning, or the honest
"resumed from a summary" note.

The sixth card button: labels now collapse below 420px (chat) / 400px (panel),
up from 360/340 — six labelled buttons need ~370px against five at ~300px, and
the row is nowrap so overshoot overflows rather than wraps. The guard added with
export already covered this; only the threshold moved.

Tests: 8 in sessions.test.js against a fixture that is sealed AND archived AND
pinned — every state a fork must not inherit. Verified non-vacuous:

  copy the end event      20/25    copy label events     20/25
  drop the (fork) suffix  21/25    drop provenance       22/25
  do not go live          23/25

All 32 suites green.

One test bug worth recording: `m.list().find(e => e.id === m.fork(id))` calls
fork() once per row against a list fetched before any fork existed. Hoisted.

…is-commented

Review flagged the comments: they still said "a fifth button" and "five labelled
buttons ... ~300px" next to a row that now renders six. Correct — and going to
fix the wording turned up a real bug behind it.

MEASURED the shipped styling in headless Chrome, six labels rendered:

  chat.html          434px    padding 0 9px, 11.5px text, gap 6, 1px border
  sessionsView.html  363px    padding 0 8px, 11px   text, gap 4, no border

The thresholds were 420 and 400. So chat.html had a 14px band — content widths
between 420 and 434 — where the labels were still painted and the nowrap row
spilled out of the card. Exactly the failure the guard was added to prevent,
reintroduced by raising the button count without re-measuring. Now 460 and 390,
both above the need with room for a wider system font.

The comments are rewritten with the real numbers and a note to re-measure when
adding a button.

The test is rewritten to assert the RELATIONSHIP rather than a regex shape. It
now parses the threshold and requires it to be >= the measured need, so a
seventh button fails until someone re-measures, and the message says why:

  chat.html: labels collapse at 420px but six labelled buttons need 434px —
  between those widths the labels paint and the nowrap row overflows the card

Boundary verified: 433 rejected, 434 accepted, and the 420 that shipped rejected.
All 32 suites green.