Recover queued and pending prompts after agent crash or unexpected exit

### Describe the feature or problem you'd like to solve

When the Copilot CLI agent crashes or exits unexpectedly while one or more prompts are queued (or a prompt is actively pending execution), all queued work is silently lost. There is no way to recover or resume it. This is especially painful during long-running sessions where the user has thoughtfully queued up several follow-on prompts — a crash wipes all of that with no recourse.

### Proposed solution

Persist the prompt queue to durable session state (e.g. the existing `session.db` / session folder) as prompts are enqueued, so that if the process exits uncleanly, the queued and pending prompts survive.

When a new Copilot CLI instance starts in the same working directory (or references the same session), it should detect the orphaned queue and offer an interactive recovery prompt:

```
⚠ Previous session exited unexpectedly with 2 queued prompt(s):
[1] "Now write the tests for the auth module"
[2] "Update the README with the new API docs"

Recover and re-queue these prompts? (Y/n)
```

Selecting **Y** re-adds them to the queue in order. Selecting **N** (or pressing Escape) discards them cleanly.

The "active/in-progress" prompt at the time of crash should also be recoverable — shown separately with a label like `[interrupted]` so the user knows it may not have completed.

### Example prompts or workflows

1. User queues 3 follow-on prompts during a long refactor. CLI crashes on prompt 1. On relaunch, all 3 are offered for recovery.
2. User queues a prompt, walks away, machine sleeps and the process is killed by the OS. On next launch, the queued prompt is waiting.
3. Network error causes the agent to crash mid-stream. The in-flight prompt is surfaced as `[interrupted]` and can be re-queued as-is.
4. User dismisses the recovery dialog — prompts are discarded and not shown again.

### Additional context

- OS: Windows 11 Pro (Build 26200 / 24H2)
- Shell: PowerShell 7.5.4
- Copilot CLI: 0.0.420 (win32-x64)
- Session state already uses `session.db` per session — persisting the queue there would be a natural fit with minimal new infrastructure.