Session permanently lost after uncontrolled laptop shutdown — null bytes + metadata corruption still unhandled in v1.0.35

### Describe the bug

Session becomes permanently unresumable after an uncontrolled laptop shutdown (e.g., battery death, forced restart, BSOD). The session directory is fully intact on disk — `workspace.yaml`, `session.db`, `plan.md`, 3 checkpoints — but the CLI refuses to load it. Neither `/resume` nor manual metadata repair restores the session.

This seems to be the same class of crash-resilience issue described in #2217 (trailing null bytes in `events.jsonl`), but triggered by a broader scenario: an uncontrolled OS-level shutdown rather than just a process kill. The OS shutdown also corrupts `vscode.metadata.json` and leaves stale lock files, creating a triple failure that manual repair of any single file cannot fix.

### Environment

- **Copilot CLI:** v1.0.35-6
- **OS:** Windows 11 / x86_64
- **Model:** Claude Opus 4.6
- **Session age:** 4 days of active use (2026-04-19 → 2026-04-23), 20 user turns, 3 checkpoints

### Session diagnostics

| Metric | Value |
|--------|-------|
| Local Session ID | `13f72ef8-d872-46f3-9459-c5f08184df08` |
| Cloud Session ID | `f71fc429-fe0a-4412-b3ed-407d0b7c6f48` |
| events.jsonl size | 8.78 MB (3,667 events) |
| Trailing null bytes | 1,206 |
| Checkpoints | 3 (all intact) |
| workspace.yaml | Intact |
| session.db | Intact (20 KB) |
| plan.md | Intact |

### What happened

Laptop underwent an uncontrolled shutdown while the session was mid-execution (turn 13). On reboot, three things were corrupted:

1. **`events.jsonl`** — 1,206 trailing null bytes from buffered I/O that never flushed. The last valid event is `assistant.turn_start` for turn 13; the turn never completed.
2. **`vscode.metadata.json`** — Written as `{}` (empty object) instead of the expected `writtenToDisc`/`firstUserMessage`/`customTitle` fields.
3. **Stale lock files** — `inuse.14004.lock` and `inuse.59196.lock` left behind from the dead processes.

### Steps to reproduce the behavior

1. Have an active Copilot CLI session with conversation history and checkpoints
2. Force an uncontrolled OS shutdown (pull power, force restart, or let battery die) while the session is actively executing a turn
3. Reboot and attempt `/resume `
4. Session fails to load

### Recovery attempts (all failed)

1. `/resume 13f72ef8...` → session not found
2. From a new Copilot session, asked Copilot to diagnose and repair:
- Removed stale lock files (`inuse.14004.lock`, `inuse.59196.lock`) ✅
- Repopulated `vscode.metadata.json` with correct fields from `workspace.yaml` ✅
- Session **still** cannot be resumed ❌
3. The null bytes in `events.jsonl` remain the blocking issue — the CLI treats the entire session as corrupted

### Expected behavior

The CLI should be resilient to uncontrolled shutdowns:

1. **On write:** Use atomic writes (write-then-rename) or `fsync` for `events.jsonl` and `vscode.metadata.json` to prevent partial/empty writes
2. **On resume:** Strip trailing null bytes, drop incomplete last event, clean stale locks, and resume — ideally from the latest checkpoint
3. **Fallback:** If full repair isn't possible, offer `copilot session repair ` (as proposed in #2490) rather than silently refusing to load a session with 3,667 valid events and 3 checkpoints

### Related issues

- #2217 — Same null-byte corruption pattern, reported at v1.0.10, still present at v1.0.35-6
- #2490 — Compound corruption (null bytes + U+2028 + oversized events.jsonl), proposes `copilot session repair` command

### Additional context

This is particularly painful for long-running sessions with significant accumulated context. The session had 20 user turns across 4 days of OfficeQA benchmark evaluation work, with 3 checkpoints marking major milestones. All the data to resume exists on disk — the CLI just can't tolerate the crash artifacts.

The fact that this same null-byte issue was reported 14 CLI versions ago (#2217 at v1.0.10, now v1.0.35-6) and is still not handled suggests this needs prioritization, especially since uncontrolled laptop shutdowns are a common real-world event (battery, Windows Update restarts, BSODs, etc.).