Feature: distinct run status when a required injected MCP server fails to initialize #20260

Use case: An operator assigns a task that depends on a required injected MCP server. When that server fails to start, the operator needs the thread to report a blocked status, not a productive one, so the failure is not mistaken for progress and the task is not marked complete.

Current behavior: #20097 (closed) described a required MCP initialize failure persisted as a completed Antigravity ACP run. The broader gap remains across providers: a run whose required MCP server failed to initialize can show as "Working" or "completed" with no distinct status, so a coordinator cannot tell a tool-init failure from real work without reading the transcript.

Requested behavior: when a required MCP server fails to initialize, the run reports a distinct status naming the server and the failure cause, and the thread does not show as Working or completed for that run. Optional MCP failures keep their current behavior. A per-server required: true flag on injected servers would let the operator choose.

API sketch:

run.status = "dependency_failed"
run.dependency = { kind: "mcp", server: "<server-name>", required: true, cause: "initialize_eof" }

Related: #20097 (same defect family, closed), #19308 (parent_not_active after compaction, distinct).