Make the runs list update itself

[artyomsv]

Goal

/runs updates itself. No F5.

New: spire-ui/src/useLiveRuns.ts

Model it on spire-ui/src/useLiveReviews.ts. Copy the socket lifecycle rather than reinventing
it — every branch in it was paid for by a live incident:

Piece	Why it is there
wsDelivered ref	The REST snapshot can land after the socket's. Applying it then overwrites fresher live state.
onclose asks fetchMe() before reconnecting	An expired handshake is answered with a redirect the browser cannot follow, so the socket fails with no useful close code. The session cookie's default life is five minutes, which makes expiry ordinary, not rare. Reconnecting blindly hammered the identity provider several times a second, forever.
needsLogin(me) -> goToFullLogin()	Asks for every URL prefix in one sequence instead of discovering each missing one a page load at a time.
isLeavingForAuth() guards the error banner	Otherwise logging out paints an alarming red failure over the dashboard for the moment before the page goes away.
setTimeout(connect, 1500)	The reconnect delay.

Frame handling, same as reviews:

• Array -> snapshot; replace the list.
• Object with a runId -> upsert by runId.
• Anything else -> ignore. Validate minimally (typeof d.runId === 'string'); a row without an id
  produces undefined or duplicate React keys and an unmergeable row.

Sort by startedAt descending with runId as tiebreak — the same order
FactoryRunProjection.list() uses, so the client never re-orders the server's page.

Change: spire-ui/src/components/Runs.tsx

• Delete the getRuns effect. Read from useLiveRuns().
• The Kind and Status selects filter the live list client-side. Consequence, and the point of
  doing it this way: a run that changes into the active filter now appears on its own. A
  server-side filter cannot do that, because the socket would have to know each client's filter.
• Keep getRuns in api.ts. Other callers use it and the endpoint stays public.
• Rename the Started header to Queued (see the sibling task on agent_started_at).

Traps

• A UI assertion like "some dash exists" is satisfied by whichever column happens to be empty.
  This has bitten this file three times — most recently when the new Proposed column supplied the
  dash the cost test was asserting on. Scope every assertion to a row or a cell:
  within(row).getAllByRole('cell').
• Array.at(-1) is not in this project's TS lib target. Use cells[cells.length - 1].
• Filter option labels collide with cell text. Succeeded is both a status pill and an option in the
  Status select, so screen.getByText('Succeeded') matches two nodes. Read from the row.
• vi.spyOn re-wraps the same module function, so call history leaks between tests in a file.
  vitest.setup.ts restores all mocks — rely on it, do not hand-roll.
• A status the union does not list falls into the success branch. refused once rendered as five
  green segments. runStatusLabel, runStatusPill and isRunUnfinished already default an unknown
  value to unknown — reuse them, never re-implement.

Acceptance

• An upserted row replaces the matching row in place, keeping sort order.
• An upsert for an unseen run id appends it.
• An array frame replaces the whole list.
• A pushed row that does not match the active filter stays hidden.
• A run whose status changes into the active filter becomes visible with no refetch.
• A socket close with an expired session calls goToFullLogin() and does not reconnect.
  Mutation-verify: reconnect unconditionally, this test must fail.
• Logging out shows no error banner.
• cd spire-ui && npm test green; npx tsc --noEmit silent.

---

Part of #147

[artyomsv]

Reviewed on PR #149 (e228dea) — implemented, one thing left

useLiveRuns.ts and useRunsSocket.ts deliver everything this issue asked for, and the session
lifecycle was copied rather than reinvented: the wsDelivered race guard, fetchMe() before any
reconnect, goToFullLogin() on an expired session, isLeavingForAuth() around the error banner.
queuedTime also earns its place — Date.parse ties on PostgreSQL's microsecond timestamps, and the
tiebreak matches the server's ORDER BY r.started_at DESC, r.run_id DESC exactly.

What is left: the filter window.

This issue chose client-side filtering, and that choice was right — a run that changes into the
active filter appears on its own, which a server-side filter cannot do. What neither the issue nor
the PR accounted for is that the client only ever holds 200 rows.

Before: kind/status went to the server, which filtered in SQL across the whole table and returned
the newest 50 matching rows.
After (useLiveRuns.ts:33, Runs.tsx:147): the newest 200 rows of any kind, filtered in the browser.

So on an instance with 300 runs whose only cancelled run is the 250th newest, Status = Cancelled
renders "No matching runs". The run exists. The screen says it does not. Warren's public instance
carries 682 runs, so this is the ordinary size rather than a corner case.

Either fix closes it:

• Say it. Showing the newest 200 runs beside the filters, and an empty state reading
  No matching runs in the newest 200.
• Or refetch server-side when a filter is active, and keep merging socket pushes into that result.

Same root, worth handling together: an upsert for a run outside the window appends it
(useLiveRuns.ts:47-50) and nothing trims back to 200, so the list drifts past its own stated size
over a long session.

[artyomsv]

Fixed in 2b6d159 and the review thread is resolved.

MAX_LIVE_RUNS is one exported constant driving the REST limit, the trim and both strings, so they cannot drift. The window is disclosed beside the filters, the empty state reads No matching runs in the newest 200, and sortRuns ends .slice(0, MAX_LIVE_RUNS) — which also closes the unbounded-growth half of the finding.

The regression test drives 300 rows with the only cancelled one at index 249, then asserts both directions: an out-of-window push does not appear, an in-window change does, and getRuns is called once.

Mutation-verified: dropping .slice(0, MAX_LIVE_RUNS) fails exactly two tests and leaves 34 passing.