TEMP local-only: keep finished agents out of the Running section (safe to delete once upstream fixes this)

[VincentBailly]

This PR is temporary and meant to be deleted

It is a local-only workaround for a fork of PrimeIntellect-ai/prime-agent.
Nothing here belongs upstream. A future rebase should drop it as soon as the
upstream code classifies finished agents correctly on its own.

Every line to remove is marked:

git grep "LOCAL PATCH(agents-view-done-in-running)"

Two hits: the guard in packages/coding-agent/src/modes/agents-view/agents-view-state.ts,
and packages/coding-agent/test/agents-view-done-in-running.test.ts, which is a local
file in its entirety.

How to prove it is safe to delete

1. Delete the guard block in agents-view-state.ts (keep the test file for now).
2. Run npx vitest --run packages/coding-agent/test/agents-view-done-in-running.test.ts.
3. If it still passes, upstream classifies finished agents correctly. Delete the test
   file too and drop this branch.
4. If it fails, upstream has not fixed it. Keep the guard.

Full revert in one command:

git apply -R /tmp/agents-view-regression/fix.patch

The bug

In the agents view, finished top-level agents stay in the Running section with the
label classifying.

classifyAgentsViewSession trusts summary.rosterStatus. The supervisor ledger only
re-publishes a roster row when a summarizer verdict text changes. When the summary
model returns an empty verdict every time, nothing changes, no flush happens, and the
row keeps activity: "working" and rosterStatus: "running" forever. On this machine
all 102,076 agent_status entries across 400 transcripts have an empty recap, so every
finished top-level agent gets stuck.

Introduced upstream on 2026-09-01 by 8d5722e (PR 1897, which dropped the
refreshWorkerSummaries pass in handleList) and 1d2e91d (PR 1900, which deleted the
one-second poll that used to re-derive activity from live state, and made classification
prefer rosterStatus).

The change

Do not trust rosterStatus === "running" when no live busy signal backs it. The row
still stays Running when it is queued, has an armed heartbeat, is actually active, has
running RLM children, or has no activeSessionId. Otherwise it is idle.

11 lines of code plus comments, in one function, plus a separate test file.

Upstream status

Not reported upstream for the agents view. Nothing merged upstream fixes it. Related
but unmerged: discussion 1873 (completed RLM worker stays active in the status APIs),
PR 1872 (auto-closed 13 seconds after opening because the contributor was unvouched),
and open PR 1967, which reports the same shape of bug for heartbeat sessions and edits
the same classifiers.

Rebase note for PR 1967: git apply --3way of this change onto its head (4ab2af3)
applies cleanly, because PR 1967 leaves the body of classifyAgentsViewSession byte for
byte the same. If PR 1967 lands, delete the hasActiveHeartbeat !== true line from the
guard and the matching test assertion, since PR 1967 removes the heartbeat to running rule.

Validation

Run in a scratch worktree through prime-agent-isolate, live daemon untouched:

• npx tsgo --noEmit: clean.
• npx biome check --error-on-warnings on both files: clean.
• npx vitest --run on 12 files (agents-view, agent-roster, daemon-agent-roster,
  daemon-session-list, daemon-protocol, subagent-summary-line,
  daemon-supervisor-lazy-subagents): 246 passed, 1 failed.
• That one failure ("arms the saved-search fetch once...") reproduces at clean HEAD in a
  separate worktree, so it is pre-existing and unrelated.

What this does not fix

Stuck queued-child rows, heartbeat ancestor promotion, the other surfaces (list,
list_agents, the subagents bar), the 25-second re-summarize loop, and the stale
classifying label that the row still shows after it moves to Idle.