Allow MCP tools to register one-shot wake events for the current agent chat

## Feature request

Allow an MCP tool invocation to explicitly register a bounded, one-shot wake event for the agent chat that invoked it. When that MCP server later signals the registered event, VS Code should queue one continuation turn in the same chat after the current turn has finished.

This is a detached, nonblocking continuation. It is not a blocking sleep, polling loop, or request to start a fresh automation session.

## Concrete workflow

1. The agent calls an MCP tool such as `set_timer({ delay: "10m", description: "check whether the deployment completed" })`.
2. VS Code registers the wake against the invoking MCP server and exact chat, returning an opaque wake/event ID. The tool call returns immediately.
3. The agent finishes its current turn. The user can continue using the chat, and no model calls occur merely because the timer is pending.
4. The timer fires asynchronously and the MCP server reports the registered ID.
5. If the registration and chat are still eligible, VS Code queues one system/event continuation in that same chat containing the ID and registered description.
6. The agent resumes with its existing conversation context and can inspect the deployment.

The same primitive would support an opted-in background process, webhook, CI result, or other event source without model polling.

## Current gap

MCP notifications can reach the client, but VS Code does not expose a supported contract by which a notification re-enters the model loop after the invoking turn has ended. MCP Tasks can represent deferred work, but task status/result delivery does not itself require the host to start another model turn.

Adjacent mechanisms do not provide these semantics:

- Agent Host Automations create a fresh session for each run rather than resume the owning chat: https://github.com/microsoft/vscode/blob/main/src/vs/platform/agentHost/node/agentHostAutomationService.ts
- The Agent Host protocol reserves schedule and external event trigger shapes, but VS Code currently advertises no event trigger definitions and rejects event triggers: https://github.com/microsoft/vscode/blob/main/src/vs/platform/agentHost/common/state/protocol/channels-automation/state.ts
- #253412 asks for a blocking `/sleep` or `/wait` command.
- #323927 reports a failure in the existing first-party background-task completion path.
- #331521 covers completion signals from owned child sessions.

None provides an MCP server with a narrowly authorized, same-chat, post-turn wake registration.

## Proposed safety contract

This should not allow any connected MCP server to inject arbitrary prompts into arbitrary chats. A narrow contract could require:

- Registration only during an explicit tool invocation, with a host-issued opaque grant bound to the MCP server identity, exact chat, event ID, and expiration.
- The host stores the description at registration time; firing the event does not let the server impersonate a new user message.
- A distinct visible system/event origin, never `user` or `human` input.
- Exactly-once consumption with duplicate/replay rejection.
- Bounded payloads, outstanding-registration limits, rate limits, and coalescing for events that arrive together.
- Safe-boundary queueing when a turn is active rather than interrupting or steering it by default; newer user input has priority.
- Registration invalidation when the chat is cancelled, ended, archived, safety-blocked, or expired.
- Normal tool permission checks on the resumed turn; a wake grant is not a tool-execution approval.

A first version could intentionally be session-local and non-durable: pending wakes disappear when the chat or VS Code process closes. Restart persistence can be a separate decision.

## Expected behavior

While a registered event is pending, the chat performs zero polling inference. When the event fires, the owning idle chat starts exactly one continuation. If it is busy, the continuation waits for the next safe turn boundary.

## Prior art

- MCP SEP-2495 proposes server-push to LLM re-entry: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2495
- Claude Code scheduled tasks provide same-session timer wakeups: https://code.claude.com/docs/en/scheduled-tasks
- Claude Code Channels use an experimental MCP capability and `notifications/claude/channel` to queue external events into the running session: https://code.claude.com/docs/en/channels-reference

Would maintainers be open to an experimental host-owned registration/wake capability, and should it live in the MCP/chat integration or build on the Agent Host external-event trigger model?

_AI disclosure: this issue was drafted with GitHub Copilot after reviewing the current VS Code implementation, related issues, MCP SEP-2495, and prior art._