Repeated Enter in the slow /resume picker splits a session: an extension's session.send wakes an invisible context (not the visible chat), which also loses tools

## Summary
After resuming a long-lived session, pressing **Enter multiple times in the `/resume` picker** appears to bind more than one active *context* to the same session. Afterward, when an extension calls **`session.send(...)`** to wake the session with an incoming prompt, the resulting turn is handled by a context that is **not** the one visible in the interactive TUI — so the user never sees it. The visible chat can also **lose extension-provided tools** (a tool that worked earlier later returns *"tool does not exist"*). It is a **single OS process and a single session id** throughout — the split is between contexts *within* the session, not between processes.

## Concrete setup (repro vehicle)
Observed with **[agent-relay](https://github.com/joniba/agent-relay)**, an extension that delivers messages from *other* Copilot CLI sessions into this one as prompts via `session.send` (so a peer session can "message" this session). This makes the bug easy to see: a peer sent several messages, and the agent **received and replied to each** — generating responses and calling the extension's send tool to reply. But all of that happened in the **invisible** context, so **none of it appeared in the user's visible chat**, even though the user was actively watching the session. The agent wasn't "acting on its own" — it was answering prompts the extension delivered; the bug is that those prompts (and the agent's answers) went to a context the user can't see or control.

## Environment
- Copilot CLI **v1.0.64-0** (also seen on 1.0.62–1.0.63)
- OS: Windows · Node: v24.x
- Session: long-lived — **~16 resumes** over several days, with **several auto-compactions**

## What seems to trigger it
1. The `/resume` picker is **slow to load** (waits on MCP/extension connections), so the **first Enter appears to do nothing**.
2. Pressing Enter again (and/or arrow-up/down → Enter) issues **additional resume attempts**.
3. The session log then records **multiple `session.resume` events very close together** — observed **3 within ~30 seconds**, two of them sharing the same parent event.

## Steps to reproduce (best-effort)
1. Install an extension that calls `session.send(...)` to inject prompts — e.g. [agent-relay](https://github.com/joniba/agent-relay), which delivers messages from other sessions as prompts.
2. Keep a session alive long enough to accumulate several resumes and auto-compactions.
3. Resume it via the `/resume` picker; while it's slow, **press Enter multiple times**.
4. Trigger the extension to `session.send(...)` (e.g. have another session message this one).
5. Observe where the resulting turn goes — the visible chat, or only the event log.

## Expected
`session.send(...)` wakes the **visible** chat; the injected prompt and the agent's handling appear in the interactive TUI (the normal path, cf. #2065).

## Actual
- The injected prompt is handled by a **separate, invisible context**: the turn is written to the session event log but **never rendered** in the TUI.
- The visible chat context **concurrently loses extension-provided tools** — the **same extension tool succeeded from one context and ~14 minutes later failed with *"tool does not exist"* from the visible context**, same process + session id, while the invisible context still had the tool.
- Both contexts append to the **same session event log**; the invisible turns are later **compacted out**, so neither the user nor the resumed visible context retains them.

## How it was diagnosed
- Verified a **single OS process and single session id** owned the session (process parent-chain + open-handle inspection) — ruling out duplicate processes.
- The event log showed: incoming `session.send` prompts with **no corresponding visible response**; the extension's send-tool **succeeding from one context and failing from the visible context minutes apart**; **multiple `session.resume` within 30s**; and several **compaction** events.
- Each turn carried its own fresh system prompt + task id, consistent with per-turn agent invocations sharing one session log.

## Impact
- Incoming prompts delivered by an extension are **answered by an invisible context** — responses are generated and tools are called (e.g. messaging peers back) with **no visibility or approval** in the user's chat.
- The visible session **silently loses tools** and can't see or control what the other context does in the user's name.
- Affected turns are **lost to compaction**, leaving no in-chat record.

## Related
- #2065 — extensions executing tool-calls without waking the chat (the normal "wake the chat" path this deviates from)
- #2543 — concurrent sub-agent events corrupting session state
- #1820 — tool set stripped mid-session

## Possible mitigations / asks
- **De-bounce / lock** the `/resume` action so repeated Enter can't bind multiple contexts to one session.
- Make `session.send` **always target the user-visible context**, or clearly **indicate** when a non-visible context handles a turn.
- Don't let a session's **tool set silently diverge** between contexts.

Start at the `/resume` picker and trace how repeated Enter presses create `session.resume` events and bind contexts. Then follow `session.send(...)` through context selection and compare it with the visible TUI path described in #2065. Done means repeated resume attempts cannot split one session, injected prompts reach the visible context, and tools do not diverge between contexts.

Written by the indexing model from the issue text.