feat(agent): publish MCP discovery phase and agent run id - #29450

Stack context

This stack replaces #29114 after review feedback that a single mcp_settled bool was underdeveloped and the change too large to review. It defines how workspace MCP discovery is communicated from the agent to chats: the agent publishes one discovery report inside the existing context snapshot (PushContextState), coderd persists it atomically with the resources, and chatd, find_tools, the create/start workspace tools, and the chat context UI all consume that same committed report.

The report has three parts. Completeness: MCPDiscovery.phase is PENDING until the agent's initial MCP reload has finished (success, failure, or zero servers all count) and COMPLETE afterwards for the rest of the process; later reloads update outcomes but never move it back. Per-source outcomes stay on the existing ContextResource rows: mcp_config rows carry structural and semantic config errors, mcp_server rows carry discovered servers (including zero tools), failed servers with a sanitized error, and a retained previous connection as OK plus a warning. Freshness: every snapshot carries the agent_run_id of the process that produced it, and the agent reports the same id in Startup, so a snapshot is known to describe the current process when the two ids match. Timestamps are deliberately not used for freshness because ready_at is agent clock and received_at is coderd clock.

Discovery completeness, per-source outcomes, turn eligibility, and the result of an actual tool invocation stay separate facts. Out of scope: continuous health monitoring, reconnect detection, automatic retries, and any retry or reload UI.

Layers, bottom to top: #29448 agent diagnostics, #29449 protocol and persistence, #29450 agent publication, #29451 chat projection, #29452 first-turn gate, #29453 context UI. Each layer builds and passes its tests on its own. The composed stack was validated end to end with remote UAT; the record is on #29453.

Why

#29449 gives the protocol a discovery phase and a per-process run id; this layer makes the agent fill them in.

Fix

The agent generates agentRunID once in agent.New, sends it in UpdateStartup, and passes it to agentcontext, which stamps it on every push. agentmcp.Manager.Report() gains the discovery phase (pending until the first reload body reaches a terminal result, then complete), and settlement fires onChange once even when the catalog is unchanged so a zero-server workspace still publishes a complete report.

agentcontext.Manager samples the MCP report once, before ResolveContext, in both resolveAndBroadcast and Resync, and uses that single sample for the server rows, the config overlays, and the snapshot's phase. A phase captured before resolution can never label a pre-settlement catalog as complete, which closes the race a review of #29114 pointed out.

Testing

Tests cover phase capture before the catalog (channel-synchronized, no sleeps), the Resync path, zero-server settlement publishing a complete snapshot with unchanged resources, the drpc conversion of run id and phase, and the agent sending the same non-empty run id in Startup and in its first push. Remote UAT of the composed stack is recorded on #29453.

Review record

• Codex review 1, requested 2026-09-17 04:29 UTC on 90487555c2: no findings (Codex Review: Didn't find any major issues).
• Codex review 2, requested 2026-09-17 05:37 UTC on 6520ca9595: no findings on 6520ca9595.
• Codex review 3, requested 2026-09-17 06:14 UTC on d9249ea1cd: no findings on d9249ea1cd.
• Codex review 4, requested 2026-09-17 06:42 UTC on b1af1ff3f1: no findings on b1af1ff3f1.
• Codex review 5, requested 2026-09-17 07:17 UTC on baed687966: no findings on baed687966.
• Codex review 6, requested 2026-09-17 07:54 UTC on 1485469260: no findings on 1485469260.
• Codex review 7, requested 2026-09-17 08:26 UTC on cf184f4385: no findings on cf184f4385.
• Codex review 8 requested on 1e1da6fb0a: pending.

This PR was authored by Xum on behalf of @ibetitsmike.