feat(chat): fold contiguous todo snapshots without losing attempts - #1846

…ough its rewrites (#1937)

## What it does for the user

While a GJC turn streams tool calls into Chat, a tool you opened now
stays open and stays where it is on screen:

- **Opening is reading.** Opening a tool row, a folded work block or a
tool's whole output stops following the end, just as scrolling up does.
New records arrive below without moving what you are reading. Jump to
latest (or New messages) brings you back to the end, and following
resumes from there. A reader who opens nothing keeps following exactly
as before.
- **GJC rewrites that keep the turns no longer reset the chat.** gjc
writes its whole session file again and renames it over the old one: on
its first save, and when it trims old tool outputs (it does the same
when it compacts). The server reads the new file as another history
(`history_id` is the file's identity), so the chat started over: every
opened detail folded, a reader's place was lost, and at phone width the
end was no longer followed. Now a new history ID whose newest page still
opens with every turn already shown, in the same places, keeps the rows,
what was opened and where you read. Each shown turn's role and start
time, each part's kind, and each tool's call id and input must be
unchanged (gjc's tool parts now carry their `toolCall` id as `call_id`
for this); what a tool answered may be trimmed. Anything else still
starts over as before: a compaction that dropped turns or moved where
the newest page starts, a new session, a cleared context, a rewind (even
one that keeps a turn's tools' names), a moved branch, or a reader
holding older pages.
- **A todo update you opened stays open.** Since #1846, contiguous todo
updates fold into one Plan row. An update you had opened turned into a
closed Plan row as soon as the next update arrived, so what you were
reading folded away. The Plan row now opens when you had opened one of
its updates, with that update still open inside it. A Plan row nobody
opened still starts closed.

## Why

#1388: "the viewport alternates between the user message and the bottom"
and "tool details that the reader expanded collapse when new records
arrive". Two causes, both reproduced on current main with GJC-shaped
records:

1. `ChatTimeline` remembered a click on a disclosure only until the next
rows change (`manualLayout` cleared on every `rows` update). Then
ChatView's layout effect and the list's size callback followed the end
again, dragging an opened running tool's header up 383–455 px on every
record.
2. gjc 0.18's session manager rewrites its file through a temp file +
rename (`rewriteEntries` after compaction eviction and tool-output
pruning; I read this from the installed gjc 0.18.12 binary). A rename is
a new inode, so `transcriptStream` gives a new `history_id` and
ChatView's read dropped the row slots, the row memories and the reader's
intent.

Since #1831, a message sent from this browser's box follows the chat
back to the end unless the reader navigated after it went out. Opening a
tool now counts as that navigation too, as scrolling up does, so a send
on its way no longer pulls the reader off a tool they opened. A gjc
rewrite that continues the chat is not navigation (the reader's place is
kept); any other new history still is.

Design: T3 Code took the other side for a reader at the very bottom
(pingdotgg/t3code#17954 keeps a reader who toggles a tool there pinned
to the bottom). Here the issue asks for the opened row to stay put while
a turn streams, and Ovis already treats scrolling up as "stop following
until I come back". Opening a detail joins that rule instead of adding a
new one, so nothing new is drawn: the existing Jump to latest and New
messages controls carry it. DESIGN.md's chat follow paragraph says so.

The server's history identity is unchanged. **HTTP contract:** `GET
/api/pane/conversation` now gives a gjc tool part its own `call_id`, the
optional field `shared/protocol.ts` already declares for Claude and
Codex; omp and pi still carry none (`server/api.contract.test.ts`).
CodeRabbit is rate-limited here, so a code-review agent's review stands
in, and this needs a real review before merging. A byte-prefix check on
the server would miss gjc's rewrites, because pruning changes earlier
records. The continuity check runs only in the chat that already holds
the turns.

## How it was verified

- New `scripts/chat-gjc-streaming-browser-qa.ts` (added to the browser
lane). It feeds GJC-shaped `message`/`toolCall`/`toolResult` records one
at a time through the real `transcriptPage("gjc-transcript")` parser and
the real ChatView → ChatTimeline → LegendList path in Chromium, at 1440
and 390 px. Three readers are covered: one who opened a running tool,
one following the end, and one scrolled up. Each runs with plain appends
and with a gjc-style temp+rename rewrite. It samples every frame from
each refresh until the view settles:
- the opened tool's header and the scrolled reader's row stay within 1
px in every frame
  - the opened tool stays `aria-expanded="true"`
  - a follower ends at the end after every record
  - Jump to latest resumes following
- On main (d3eefef, before this branch was rebased) it fails 62
assertions:
  - header displacement −383 to −455 px per record
  - `aria-expanded="false"` after a rewrite
  - the scrolled reader's row lost after a rewrite
  - the 390 px follower 179–205 px short of the end
- in a chat that still fit the screen when the tool was opened, the
opened tool dragged up to 1502 px once later records overflow it
- On this branch every scenario holds at 0 px (20 scenarios, rebased on
ddee8be). Current main (ddee8be) still fails 62 assertions.
- Its `todo` scenario (added with the rebase) opens a gjc `todo_write`
update and appends the next one, plainly and through a rewrite: the Plan
row's head stays where the opened update's head was in every frame, it
is open, and the update read stays open in it. Run against the commit
before that fix, the script fails only those 16 todo assertions.
- `server/conversation.test.ts` runs a gjc rewrite through the real
parser: the same calls written again continue, and a rewind that reads
the same file again under another call id, later, does not.
- `src/lib/chatRows.test.ts` covers `continuesHistory`: continuation, a
dropped/moved/retimed turn, a page that starts later (dropped first
turns), a rewind that puts another call of the same tool in a shown
place (other input or call id), another source, scrollback, empty and
untimed pages.
- Its `jump` scenario opens a tool and takes Jump to latest at once;
closes and reopens it and jumps again; closes it while following,
scrolls away and jumps back; and does that again but scrolls back to the
end by hand. After each Jump the last row grows with no record between,
and the end is followed. The script counts an answer as served only once
the chat has read its body and React has committed after it.
- `scripts/chat-virtual-browser-qa.ts` passes at 1440 and 390 px, dark
and light (paging, pagination, virtualization, selection and disclosure
restoration). The other chat browser scripts run in this PR's browser
lane.
- `scripts/todo-snapshots-demo-regression.ts` passes, and so do
`chat-local-send-follow-demo-regression.ts` (#1831),
`chat-browser-qa.ts` and `chat-tool-paths-demo-regression.ts` on the
rebased branch.
- `bun run check fast` passes: typecheck, build, generated files,
workflow syntax, 6772 unit tests.
- Reviewed by a code-review agent (no HIGH; its one real gap, a chat too
short to scroll re-arming follow, is fixed in the second commit) and by
Codex Sol 6.1 (no HIGH; three MEDIUM findings on the history
continuation are fixed in the third commit: it applies to gjc only and
needs each shown part's kind and tool to match, an older-page read in
flight is dropped, and the kept reading place moves to the new history
ID). A Codex re-review of that commit found no remaining HIGH or MEDIUM
issue.
- After the rebase onto current main, Codex Sol reviewed the rebase
delta. The two conflict resolutions with #1831 were clean. It found one
MEDIUM, the #1846 todo row folding an update the reader had opened,
which the last commit fixes. Its re-review found one more MEDIUM (a
remounted Plan row lost the openness it had inherited), fixed in the
same commit; its 13-case repro passes.

Not covered: native iOS/Safari, a gjc compaction that drops turns (it
starts over, as before), real gjc runs (the records are synthetic and
the rewrite is simulated as gjc does it), and a reader who has loaded
older pages when gjc rewrites. That reader still starts over, because
those pages were read from the old file.

Fixes #1388

---------

Co-authored-by: mp <mp@local>

… each update's own input and output (#1601) (#2161)

## Change

Fixes the two gaps #1601 still had after #1846 folded contiguous todo
updates into one Plan row.

- **Focus survives the fold.** When the agent's second todo update
turned the single row the reader was on into a Plan row, the focused
button left the page and the keyboard focus fell to `<body>` (expansion
already carried over since #1937). A row head now records in its
timeline row's memory that it holds the focus (`useRowFocus`,
`src/lib/chatRowState.tsx`). The head drawn in its place in the same
render takes the focus back: the same update inside the opened run, or
the run's own head when it is folded. Focus the reader moved elsewhere
is never taken, a head that leaves with no replacement ends its record
(a row scrolled back or reopened later never grabs the focus), and a
fold while the reader is in another app keeps it too.
- **Each attempt shows its own call.** An update opened inside the Plan
row showed the parsed list again, which the run already shows above it.
It now shows the input the agent sent (JSON indented, under "Input") and
the output it got back, including "Show the whole output" for a cut one.

Design: the Codex and Claude apps keep one row per action under the turn
and keep the reader's place while a turn streams. This follows that, as
#1846's DESIGN.md entry does; the entry now records both rules. "Input"
is translated into Korean, Japanese and Chinese. A `changelog.d/`
fragment is included.

Closes #1601.

## Validation

- Regressions that fail before and pass after:
- `scripts/chat-gjc-streaming-browser-qa.ts` (browser lane): its todo
scenario now asserts the focus is on the opened update inside the Plan
row after the next update arrives. On main all four variants (1440/390 ×
append/rewrite) failed with the focus on BODY; on this branch all pass.
- `src/components/ChatTurn.test.ts`: an opened two-update run shows each
update's raw input and output.
- `scripts/todo-snapshots-demo-regression.ts`: 21/21 pass (1440/390,
light/dark, Korean), including "open, focused run through append and
poll".
- `bun run check fast`: green on b4d51fd (unit tests 7886 pass, 0
fail). On the final head 12c0c34 (one line added to `useRowFocus`),
typecheck, build and generated files pass; the unit tests had one
timeout in an untouched file, `scripts/ci-browser.test.ts` "creates
evidence under .ci when CI has no CHECK_DIR" (5029 ms on a 5 s limit at
host load ~66). Rerun on its own, it passes in 3.4 s (7/7).
- Not covered by an automated test: the background-window case (headless
Chromium always reports the page focused) and StrictMode's rehearsed
unmount (the browser fixture renders without StrictMode). Both were
reviewed at source level and confirmed by Codex's last round.
- Reviews: omo-native-code-reviewer PASS (its MEDIUM, a window blur
ending the record, fixed; the over-long DESIGN.md line fixed; other LOWs
out of scope). Codex Sol 6.1 Fast xhigh: round 1 MEDIUM (a stale record
after a head left with no replacement) fixed; round 2 MEDIUMs
(StrictMode rehearsal, focus events deferred while the window is in the
background) fixed; the confirmation round on the final head PASS with no
findings.