test(server): follow #7151's tool status onto non-Prime rows

[rynfar]

pylon has been red since #62 merged. This fixes it.

Adopting #7151 in that batch carries the adapter's status onto every tool lifecycle row, not just Prime's. ProviderRuntimeIngestion.activity.test.ts asserted the opposite for tool.started and tool.completed.

Which side gives

Those assertions described the behavior before #7151 rather than guarding a Pylon invariant — the test's actual subject is that Prime-specific handling does not leak into non-Prime paths, and that still holds. So they follow upstream.

The alternative was re-gating status to Prime only. I tried that first, and it fails #7151's own test, which expects status: "inProgress" on a non-Prime item.started. The two cannot both hold, and staying in step with upstream wins where Pylon has no stated reason to diverge.

Worth flagging: an earlier xhigh review raised exactly this as finding 9 — non-Prime tool.completed carrying raw status replaces the client's guaranteed "completed" default with an unvalidated passthrough, so an adapter forwarding a stale inProgress would render a permanently-spinning tool. I recorded it as an upstream design decision. That risk is real but latent: the same review confirmed every current adapter reports a terminal status on completion. It stays in the ledger.

How this got in

Two process failures, both mine:

• My targeted test run covered ProviderRuntimeIngestion.test.ts and missed the .activity.test.ts sibling.
• I merged chore(upstream): adopt the 2026-08-20 T3 Code batch #62 without checking that pylon went green afterwards.

Verification

• Both ingestion suites pass: 86 tests.
• Full server package: 3074 passed, 1 pre-existing failure in accountDrainEndToEnd.test.ts that is unrelated and not caused here — it fails identically on unmodified origin/pylon, and passes in CI in 59ms while timing out locally at 60s. That is a local environment difference, not a regression.
• Formatting clean.

Model: Claude Opus 5 in Pylon.

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	12.6 KiB	13.5 KiB	+860 B (+6.7%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.3 KiB	6.9 KiB	+632 B (+9.8%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.3 KiB	6.6 KiB	+228 B (+3.5%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	51.8 KiB	55.0 KiB	+3.2 KiB (+6.1%)	66.4 KiB	✅
Codex	Live turn messages	16	16	0 (0.0%)	21	✅
Claude	Total thread wire	12.6 KiB	13.4 KiB	+863 B (+6.7%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.3 KiB	6.9 KiB	+624 B (+9.7%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.3 KiB	6.6 KiB	+239 B (+3.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	52.7 KiB	55.8 KiB	+3.2 KiB (+6.0%)	66.4 KiB	✅
Claude	Live turn messages	16	16	0 (0.0%)	21	✅

Baseline: f89e16d · PR result: f5228b9 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.0 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.