Subagent spawn with a pinned non-default model intermittently fails with `key is missing`, and the broken session poisons subsequent chats

### Type: Bug

### Environment
- GitHub Copilot Chat: `0.55.0`
- VS Code: `1.127.0`
- Agent mode with a custom subagent (`.github/agents/*.agent.md`) that pins a `model:` different from the active session model.

### Summary
When a custom agent is spawned as a subagent (`runSubagent`) and its frontmatter pins a `model:` that differs from the parent session's active model, the subagent's **first** request to the Copilot backend intermittently fails during request assembly — before any model round-trip occurs — with:

```
Agent error: Sorry, your request failed. Please try again.
Reason: key is missing
Note: GitHub is currently experiencing a service disruption. ...
```

The appended "service disruption" note is misleading — there is no outage. An immediate retry with identical inputs on the same pinned model succeeds.

### Repro
1. Run agent mode on session model A (observed: `claude-opus-4.8`).
2. Spawn a subagent whose agent file pins `model: Claude Opus 4.6 (copilot)` (model B).
3. Observe the first spawn fail with `Reason: key is missing`; retry succeeds.

### Expected
Switching models on subagent spawn should assemble a valid request (or transparently retry), not fail with `key is missing`.

### Actual / evidence (from debug logs)
- Parent session ran entirely on `claude-opus-4.8` (8 model calls, all ok).
- Round-1 target subagent inherited the session model → succeeded first try (no model switch).
- Evaluator subagent pinned to `claude-opus-4.6`: **attempt 1** started, loaded context, then ended ~2.5s later with **zero `llm_request` events emitted** → `key is missing`. **Attempt 2** (identical inputs, same model) emitted 9 successful `llm_request`s.
- Failure signature: request rejected at API boundary during model resolution, pre-first-token; transient (self-heals on retry).

### Additional symptom: broken session poisons subsequent chats
After the failing session, the error leaks **outside the agent**: starting a **new chat** then fails on **any** model/agent request with the same error, as long as the broken session's debug logs are present. New/unrelated chats do not recover until the poisoned session state/logs are cleared, suggesting the bad request state persists beyond the originating session rather than being isolated to it.

### Impact
Breaks automated multi-subagent workflows (e.g. loop/evaluator patterns) where a subagent is pinned to a non-default model — and worse, the failure is not contained: it cascades into subsequent unrelated chat sessions until cleared.