fix(room): give a reloaded run's work band to the reply the history shows

[91jaeminjo]

Summary

On a reloaded thread, a run's work band now goes to the replies the timeline
actually shows. Before, replayToTrackers re-derived "which reply spoke" from
the stored events (non-blank content plus a stored TEXT_MESSAGE_END). That
copy of the history replay's rule had drifted from the original, so the band
landed in the wrong place:

• A reply cut off by RUN_ERROR / RUN_FINISHED before its end. The
  history replay commits the partial reply (commitPartialTextOnTerminal),
  but its band fell back to the run's no-response tile.
• A reply another reply opened over. It is never committed, but it still
  took the band, which then pointed at a tile that never renders.

replayToTrackers now takes the ThreadHistory and hands a run's work only
to a reply in history.messages with non-blank text. The assistant-role
check stays where it was, on the AG-UI TEXT_MESSAGE_START event.

Changes

• historical_replay.dart: takes ThreadHistory; one speaking set built
  from history.messages replaces the per-run ended / spoke sets. Doc
  comment updated to match.
• thread_view_state.dart: passes history instead of history.runs.
• Tests:
  • Replay tests build their history through the real client
    (storedHistory) instead of passing raw bundles.
  • New live/reload parity test: a reply the run fails partway through.
  • New replay tests: a reply the history does not show takes no band; a
    call left open when the stored events run out is failed. The second
    pins endedOn, which no test covered before.
  • Removed nine replay tests that pinned no decision another test does not
    already pin. Checked by breaking replayToTrackers 19 different ways:
    every break caught before the removal is still caught after.
  • Corrected two parity-test comments that still described the old rule.

Notes

• The backend gives every assistant message a fresh uuid4() id, so a
  message id shared across runs, which would make one run's band overwrite
  another's, is not handled.
• thread_view_state_test.dart's "a send from a disposed view does not
  throw" still prints a signal warning: … read after disposed. It predates
  this change, and there is no cheap fix.

Test Plan

• flutter test test/modules/room: 1639 pass
• flutter analyze: no issues
• Manual testing: reload a thread whose run errored mid-reply and check
  that the reply carries its work band

Related Issues

Related to #602

🤖 Generated with Claude Code