feat(site/src/pages/AgentsPage/components/ChatConversation): fold each finished turn into one Working block - #31025

…working block key comment

…e parked-turn wiring and drop a duplicate split test

…rration joining loaded work on a partial page

The narration paging test checked only the first page, where narration
waits, and the fully loaded turn. Neither fails if the open-block clause of
the narration fold is dropped. The page that loads the older work but not
the prompt now asserts that narration after that work folds into its block.

…ing narration once loaded work joins it

Narration at the top of a partly loaded ended turn waits like text until
work joins it. When that work had no steps, such as reasoning before the
final answer, the block it formed counted no narration and was dropped,
so the rows rendered unfolded until the prompt loaded and then folded.
Narration that waited now marks its block the way narration that folds
directly does, so the partial page matches the loaded turn.

…ten output kinds and the working block key doc

outputKindOf accepted a missing item only because Array.prototype.at
types the last item as possibly undefined, though no output piece is ever
empty, and it classified that missing item as a file. It now takes an
item. The non-response kind is "file", since file references fall in it
too. The WorkingBlock key doc now says the key is liveKey while the
block is live.

…e waiting narration note to its join

The pending text comment keeps its two lines, and the reason waiting
entries record narration now sits on the loop that uses it. The
WorkingBlock key doc says "otherwise" instead of "once complete", since
an interrupting or parked turn's block is not live yet may still grow.
The new paging test's name says what it compares.

…ting text out of step-less blocks

Waiting entries record whether they are narration, and only narration
keeps a step-less block. No test failed when every waiting entry counted as
narration, which folds a tool-less turn's text before its reasoning. The
text case now shares the narration test's fixture and asserts both layouts
stay unfolded.

…er history can change a live block's key

A live block keys on liveKey, which older history can change once it
loads the block's prompt or earlier blocks, so the WorkingBlock key doc
limits its stability claim to the key a block has once it stops being
live.

…place focus loss to the block summary

A slice that stays mounted can still drop the focused element, as when
streaming reasoning collapses because the next call joins its piece.
The element at the same place in that slice is then another control,
so the restorer matches a twin only when the focused element's slice
itself unmounted, and otherwise falls back to the block summary. Review
follow-ups also name the position counted from the end, use `at` for
it, and move the whole-row note to the `SlicePosition` doc.

… the focus restorer's class comment

…e the focus restorer's twin by its pieces

…t why the text-before-second-step fixture shares a row

…xpanded tool open when its row folds

A running or parked row holding a tool, text, then another tool renders
a slice in each of two blocks, keyed message:<id> and message:<id>:1.
The ended turn's fold merged them into one slice keyed on the first, so
the ChatMessageItem holding the second tool remounted inside the
surviving block and a tool the reader expanded collapsed.

A folded slice now takes the work ordinal of its newest work, the key the
open turn gave that work's slice.

…ailing reasoning block open when the turn stops

An open turn with a tool block, then text, then a live block of only
reasoning shows that reasoning block. When Stop or an error ended the
turn, the fold kept the live key of the earlier block with steps, so
the reasoning block, the newest block the turn showed, remounted and
collapsed.

The fold now keeps the newest open-turn block, and falls back to the
newest block with steps only once text or a row that never folds closes
a block of only reasoning, which an open turn shows inline.

…s on the answer when narration before it folds

…e fold key comments to three lines

… the open-turn block ordinals and shared fold fixtures

… the result fixture by the calls it answers

…s on a control in a middle block when its row folds

…focus twin lookup inside its piece

A control in a middle block that the fold remounts may be gone after the
fold, such as the output of a command the reader expanded. The twin lookup
counted the piece's controls on to the end of the merged slice, so focus
landed on a control of the next piece. It now stops at the next piece's
marker, and a piece with fewer controls falls back to the block summary.

Also moves the piece-start calculation out of BlockList, names the
fixtures of the three-step row, and indexes the twin with at().

…re a piece's focusables end

The doc on getPieceFocusables repeated its name. It now states the bound
at the next piece's marker, which the name does not carry.