Consolidate run-status tone onto react-ui's canonical map

[TheGreatAxios]

Summary

• Fixes a design-review finding: Routines, Insights, and Mission Control each grew their own run-status → tone opinion instead of reading react-ui's canonical RUN_STATUS_TONE (workflow-run.ts), and disagreed on a shared status — a cancelled run read neutral grey on Routines and amber warning on Insights.
• Routines' RUN_STATUS_TONE was an exact-name shadow of react-ui's export (same identifier, different object, no import relationship). Removed outright; RunStatusCell now normalizes the platform's run-status strings onto react-ui's RunStatus and reads tone via a small runStatusTone helper.
• Insights' statusTone mapped stopped/cancelled → warning; canonical says stopped → neutral. Rewrote it to normalize WorkflowRunStatus (@intx/types) onto RunStatus and delegate to RUN_STATUS_TONE.
• Mission Control hand-picked "accent"/"info" literals that happened to already agree with canonical — now reads RUN_STATUS_TONE.awaiting/.running directly so it can't silently drift.
• Agents' AGENT_ROSTER_STATUS_TONE is a genuinely different enum (AgentRosterStatus) and is left as-is per the design review — exported it so the new parity test can assert it still agrees with canonical on the one status name (running) the two vocabularies share.
• Evals' page already did this right (imports canonical, no local map) — untouched.

Guard

Added apps/web/src/pages/run-status-tone-parity.test.ts: a unit test that calls each page's real status-tone code and asserts it equals react-ui's RUN_STATUS_TONE for every status name the two vocabularies share. Chose a test over a scripts/checks/-style static scan (the pattern react-ui-drift.ts already uses in this repo) because the actual bug was a value mismatch inside a switch statement, not a detectable syntactic shape — verifying "does this tone equal canonical" needs to run the real code, not parse it. A regex/AST scanner would need to handle both switch-statements and object literals to catch this class, which risks becoming exactly the general-purpose lint framework this ticket says not to build. The test is cheap, precise, and already wired into apps/web's existing bun test run.

Confirmed red/green: temporarily reintroduced the original stopped → "warning" bug in statusTone and the test failed with Expected: "neutral", Received: "warning"; reverting to the fix makes it pass again. Full apps/web test suite (293 tests) stays green, tsc --noEmit and eslint are clean on the changed files.

Other same-name-different-object shadowing noticed (not fixed, out of scope for this ticket)

• apps/web/src/pages/agent-detail-page.tsx:90 declares STATUS_TONE: Record<"deployed" | "stopped", BadgeTone> with the exact same shape/values as agents-page.tsx's DEFINITION_STATUS_TONE (deployed: "success", stopped: "neutral") — different identifier, same object, two files. A genuine duplicate, just not the RUN_STATUS_TONE class this ticket targeted.

Test plan

• bun test src/pages/run-status-tone-parity.test.ts (apps/web) — 4 pass
• Reintroduced the original bug, confirmed the guard fails; reverted, confirmed it passes
• bun test ./src (apps/web) — 293 pass, 0 fail
• bunx tsc --noEmit -p apps/web — clean
• bunx eslint on changed files — clean