Kickoff prompt silently dropped when a new session is created — worktree provisioned but agent never receives the message

### Describe the bug

When a new session is created from the app with an initial prompt, the git worktree, branch, and CLI session are provisioned successfully, but the kickoff prompt is never delivered to the agent. The session sits idle forever with no assistant response, and the prompt text is lost — it is not persisted in the session event log, the local session store, or the cloud session store, so it cannot be recovered.

From the user's perspective a workstream appears to have been created, but none of the instructions they gave were received or performed. This happened at least 6 times in a single day on one machine.

### Affected version

```
GitHub Copilot CLI 1.0.79-5.
```

### Steps to reproduce the behavior

I have not found a deterministic trigger, but the failure has a consistent signature in the process logs. For an affected session, the only inbound requests are `session.create`, `session.resume`, and `session.getMessages` — no turn/prompt request ever arrives:

```
21:09:50 Received session.create request
21:09:55 Received session.resume request <- x3 within 0.4s
21:09:56 Received session.resume request
21:09:56 Received session.resume request
21:09:56 Received session.getMessages request
21:10:04 Received session.getMessages request
(nothing further — no prompt ever delivered)
```

A second affected session shows the identical pattern, and was later torn down without ever running a turn:

```
21:05:29 Received session.create request (branch russrimm-urban-waffle)
21:05:33 Received session.resume request <- x3 within 0.4s
21:05:33 Received session.resume request
21:05:33 Received session.resume request
21:05:34 Received session.getMessages request
21:05:58 Received session.getMessages request
21:18:34 Received session.destroy request <- never received a prompt
```

The corresponding `session-state//events.jsonl` contains only `session.start`, `session.permissions_changed`, and `session.remote_steerable_changed` — no `user.message` event. Some affected sessions have no `session-state` directory at all.

Two observations that may be related:

1. **Triple `session.resume` inside ~0.4s.** Both failed sessions show `session.resume` fired three times in rapid succession immediately after `session.create`. This looks like a race during session initialization.

2. **Kickoff prompts appear to be queued, and the queue sometimes never flushes.** Sessions that *did* work the same day showed very long delays between creation and their first turn:

| Session | Created | First turn | Delay |
|---|---|---|---|
| `0d336342` | 20:34:41 | 20:47:36 | ~13 min |
| `70c938fc` | 20:42:54 | 20:52:39 | ~10 min |

Session startup itself is slow — MCP servers finish loading 12–27s *after* `session.resume`. If the prompt is dispatched during that initialization window without a retry or acknowledgement, it appears to be dropped.

### Expected behavior

The kickoff prompt should be delivered reliably, and never silently lost. Specifically:

- Prompt delivery should be acknowledged and retried until the session accepts it, rather than fire-and-forget during session initialization.
- The prompt text should be persisted at enqueue time (before delivery is attempted), so it survives a failed handoff and can be replayed or at minimum shown to the user for re-submission.
- If delivery ultimately fails, the session should surface a visible error instead of sitting silently idle, so the user knows to resend rather than assuming work is underway.

### Additional context

- Operating system: Windows 11 Enterprise 10.0.26200.0
- CPU architecture: AMD64
- Client: `client_name: github/autopilot` (sessions created via the app, each with its own git worktree)
- Sessions observed with zero turns on 2026-08-09: `81740d62`, `6cd2559d`, `39906778`, `c8b74c18`, `2f8a8518`, plus one more that was created empty and only became usable when the user manually typed into it.
- Config note (possibly contributing to slow startup): duplicate MCP server registrations across plugins are logged as errors at startup — `playwright`, `microsoft-learn`, and `workiq` are each defined by two different plugins.

**Secondary bug — orphaned worktree left on disk.** When one of these empty sessions was destroyed, cleanup was only partial: the worktree's `.git` file was removed and `git worktree list` marked the entry `prunable`, but the working directory (including `node_modules`) was left behind on disk. It had to be removed manually with `git worktree prune` plus a forced directory delete. Sessions that are torn down should clean up their worktree fully, or leave it fully intact — not half-removed.

Start by tracing the session.create, session.resume, session.getMessages, and session.destroy request handlers and inspect session-state//events.jsonl for prompt persistence. Reproduce the rapid resume sequence from the process logs, then verify that kickoff prompts are acknowledged, retried or surfaced as errors, persisted before delivery, and that destroyed sessions clean up their worktrees completely.

Written by the indexing model from the issue text.