fix(fleet): move Fleet Manager TUI blocking I/O off the Textual event loop

[Jason Robert (jrob5756)]

Closes#437.

What was wrong

Three sites in the Fleet Manager TUI did blocking filesystem and subprocess
work directly on the Textual event loop, so the whole UI stopped responding
while they ran:

1. screens/runs.py::refresh_runs — every ~2s, on the event loop: a
   directory scan, a JSON parse per record, a per-record liveness probe, a
   destructive prune, and a derive_run_summary() per row. This scales with
   fleet size, on the screen a user leaves open.
2. screens/history.py — build_history_entries() read up to
   keep_last (default 200) event logs in full before History painted.
3. The dashboard-open path — _wsl_open shells out to powershell.exe
   with a 15s timeout; on a host where that is slow, the TUI froze for the
   full 15s with no sign it was alive.

What changed

Each now runs in a worker (@work async def + await asyncio.to_thread(<collector>)), with the render half back on the event
loop after the await — matching the pattern screens/new_run.py,
step_detail.py, registries.py and providers.py already established.

Two sites beyond the three in the issue get the same treatment:

• run_detail.py's poll, which has the same shape as Runs'.
• actions.py::kill_runs — stop_records's signal-and-poll escalation
  ladder can take seconds, and being an async def does not move a blocking
  call off the loop by itself.

Design notes

• An overrunning poll drops the next tick rather than queueing behind it.
  Each screen's refresh_*() entry point stays a synchronous dispatcher
  (so it is still callable from on_mount, set_interval and action
  handlers), guarded by a plain _refreshing boolean. Deliberately not
  @work(exclusive=True), which would cancel the in-flight worker instead of
  skipping the new tick.
• The _refreshing flag is set in the synchronous dispatcher, not as the
  first line of the worker — a @work method's body does not start running
  until the event loop schedules it, so setting it inside would let a second
  tick slip through.
• A dedicated Static (#runs-loading / #detail-loading /
  #history-loading) shows a dim muted("Loading…") line from on_mount,
  hidden once the first result lands, covering the frame between mount and
  the first collector result.
• Collectors are module-level functions so they are trivially unit-testable
  and safe to hand to asyncio.to_thread.

Test caution worth knowing about

A pilot test that presses a key opening a modal (kill confirm, gate options)
and then needs a second keypress to resolve it must use a plain await pilot.pause() between the two, never tests/test_fleet/conftest.py::settle.
settle awaits app.workers.wait_for_complete(), and the action's own
@work method is suspended on push_screen_wait until that second
keypress — so awaiting it first deadlocks the test. This is documented in
AGENTS.md alongside the rest.

Validation

• uv run pytest tests/test_fleet tests/test_cli/test_bg_runner.py — 666
  passed, 1 skipped.
• make check — ruff, ruff format, and ty all clean.

AGENTS.md, CHANGELOG.md and docs/fleet.md updated.

[Jason Robert (jrob5756)]

Review round applied

Ran a seven-agent code review over this PR. Three agents independently found the same regression, and two reproduced it empirically, so the branch has been rebased onto main and force-pushed with the fixes squashed in.

Blocking, all fixed

1. Duplicate gate/failure notifications. The notifier was pruned against the rows that rendered rather than the records that were read, so a run whose summary failed to derive on one tick was forgotten and re-fired on the next successful one — the once-per-transition contract _refresh_worker's own docstring exists to protect. Reproduced: main fired 1 notification, this branch fired 2. _collect_runs now returns a RunScan carrying seen_run_ids and failed alongside the rows.
2. A total derivation failure rendered as the "No runs — press n to launch one" empty state, with _displayed_records emptied so k/K/enter became silent no-ops. An operator was affirmatively told nothing was running while their workflows were still burning tokens.
3. A persistent scan failure left the screen on "Loading…" forever — no table, no empty state, no notification, no timeout.
4. History rendered a read failure as "No run history yet." — a positive claim of absence, permanent because that screen loads once with no poll to self-heal.

Also addressed

Guard flags are released if worker dispatch raises; an explicit post-kill/post-gate refresh is coalesced via _refresh_pending rather than dropped (those callers promise the table reflects what they just did, and on the slow-fleet case this PR targets a scan is in flight most of the time); History's render is guarded like the other two screens, since @work defaults to exit_on_error; _open_dashboard_worker gets its missing except; the stop_records diagnostics the silent console was discarding are now logged, including the --force remedy for an unconfirmed kill; and the four if not self.is_mounted: return guards are gone — Textual never resets _is_mounted (verified against the source, a pop probe, a 40/40 race probe and coverage), and Widget._on_unmount already cancels the worker.

Nits: the loading line is declared in compose() (loading.display = True was a no-op), reuses the existing unused .notice app class instead of new per-screen CSS, and "Loading…" moved into theme.py — five screens were spelling it three ways.

Verification

Every new test was checked against a mutant that reintroduces the bug it covers. That mattered: the first version of the notifier test passed against the regression, because a total-failure fixture takes the new error branch and never reaches the prune. It now uses a partial failure and genuinely kills the mutant. Eight mutants, eight caught.

settle() is now bounded — this project has no pytest-timeout, so the documented push_screen_wait misuse hung the entire run rather than failing one test.

Rebased onto #448, which landed in the same two files. Its test_the_poll_keeps_running_under_a_modal needed a settle() since the scan is no longer synchronous; I mutation-checked that its contract ("only the render is suppressed while covered, never the poll") is still enforced afterwards.

575 fleet tests pass; make check clean.

The one recommendation I did not take: extracting a PollingScreen base class. The reviewing agent argued against it and I agree — the two polled screens differ in failure contract, and 5 of the 7 threaded-load screens would not use it.