fix(tui): a fork continues when a turn lost its tool call

[gaord]

Summary

Continuing a forked conversation could fail on the first message with
400 No tool output found for tool call …, and retrying the fork answered
cannot identify an exact saved-history boundary. Both come from the same
place, found while using the fork capability from #6580 on a compacted
conversation.

A turn whose tool call never produced a result — a failed tool, or a process
that died mid-call — is persisted as one tool_call item that carries the call
and its failure text, with no tool_result_for item. A history rebuilt from
the turn records (what a fork of a compacted source does) therefore emitted the
call alone, and two things followed:

• the response after the lost call was glued into the same assistant message
  (thinking, call, thinking, call), because the missing result is what
  failed to flush the first response — the live transcript held those as two
  separate messages; and
• the request-time repair answered the call by inserting a result next to that
  merged message, which the Responses API reads as the first call never being
  answered, so every turn the fork ran failed the same way.

The recovery projection had a second, independent problem: a fork inherits the
source's compaction summary as its system prompt, so on its first load the
engine installs that checkpoint message into the fork's own document. No turn
record reproduces it, so the document read as drifted from the records it was
rebuilt from, and the next cut — /undo, retry, fork-again on the fork itself
— refused.

What changed

• reconstruct_messages_from_turns_with answers a call whose item records no
  outcome, where the live transcript held the answer: the item's own failure
  text for a failure, and the repository's interrupted-call notice for a call
  the process never finished (CRASH_REPAIR_CONTENT, now the one spelling the
  session repair and a rebuild share). An answer is paired only with a call the
  rebuild actually emits — a snapshot with no tool name is skipped (serve --http: threads with tool-call history fail with 400 missing field name after a runtime restart #5823), so
  the identity rule is checked here too — and a call the turn already answers
  with its own tool_result_for item is left alone. A call still running is
  deliberately untouched: the engine is waiting for its result.
• The recovery projection reads an engine-owned compaction checkpoint as the
  engine's own message rather than as a prompt no record holds, so a document
  carrying one is still cut at the turn the caller names.
• SUMMARY_HEADER becomes crate-visible so the projection's recognition rule
  and its tests share one literal.

No new layer; the existing tool_history_repair module keeps ownership of the
interrupted-call notice.

Testing

Run against the commit this branch was rebased from (d49fb9d99); the branch
is based on 2d9613bac, whose changes to these files are in unrelated regions
(sub-agent display names, custom-thread route tests), so CI covers the rebased
tree.

• cargo fmt --all -- --check — clean.
• cargo clippy -p codewhale-tui -p codewhale-runtime --all-targets -- -D warnings -A clippy::uninlined_format_args -A clippy::too_many_arguments -A clippy::unnecessary_map_or -A clippy::collapsible_if -A clippy::assertions_on_constants — clean.
• cargo test -p codewhale-tui --lib runtime_threads — 240 passed; 1 failed; 2 ignored. The failure is host_goal_loop_kickoff_arms_one_continuation_and_parks_at_engine_cap, a load-sensitive goal-continuation test: it fails the same way on the unmodified checkout under the same parallel load and passes when run alone. Not from this change.
• cargo test -p codewhale-tui --lib compaction — 154 passed; 0 failed.
• cargo test -p codewhale-tui --lib session_manager — 107 passed; 0 failed; 1 ignored.
• cargo test -p codewhale-runtime tool_history_repair — 8 passed; 0 failed.

All three new tests were shown failing with the two behaviours disabled, and
passing with them:

• a_rebuilt_turn_answers_a_tool_call_whose_outcome_the_store_lost — a turn
  whose first response lost its call is rebuilt as two responses, each with its
  own call and its own answer. Without the fix the fork's document came out as
  ("assistant", ["thinking", "tool_use", "thinking", "tool_use"]) plus a
  repair notice, and the calls were left unanswered. The second half retries the
  fork itself, over a document carrying the engine's checkpoint.
• a_compaction_checkpoint_is_not_a_kept_prompt — without the fix the prompt
  walk returns None (the refusal) on a transcript that carries a checkpoint;
  with it, the boundary is found.
• a_lost_call_is_answered_only_where_its_own_outcome_is_known — the failure
  text, the interrupted-call notice and every status this must leave alone.

Checklist

• This PR adds a new layer/module/abstraction — it names or deletes the layer it replaces
  → no new layer; the existing repair module keeps the notice's ownership.
• Updated docs or comments as needed
• Added or updated tests where relevant
• Verified TUI behavior manually if UI changes → no UI change (engine-side history).
• Harvested/co-authored credit uses a GitHub numeric noreply address

CHANGELOG.md and crates/tui/CHANGELOG.md are deliberately untouched
(CONTRIBUTING: entries are written on main at merge time).

What this does not address

Documents an older build already wrote keep the merged assistant message, so
cutting one forward (undo/retry/fork on that thread) hands the shape back. A
fork built from the turn records — the path a compacted source takes — is clean
with this change, so branching again from the conversation produces a healthy
history. Healing an existing document would mean splitting a merged assistant
message (and its results) in the history-repair layer, which is a wider change
than this fix; left out deliberately.