Refinalizing a task graph leaves stale WPCreated/TasksCompleted authority

## Summary

Re-running `spec-kitty agent mission finalize-tasks` after a pre-implementation task-graph revision does not supersede existing local lifecycle definitions. The generated `tasks.md`, `wps.yaml`, and `lanes.json` describe the new graph, while append-only `status.events.jsonl` retains stale `WPCreated` payloads and the old `TasksCompleted.wp_count`.

`status.json` can simultaneously materialize zero work packages, yet `agent tasks status` reports the new planned graph and `agent status validate` passes.

## Reproduction

1. Finalize a 3-WP graph: WP01 witness, WP02 lifecycle, WP03 review.
2. Before implementation, revise/finalize a 4-WP graph: WP01 witness, WP02 command, WP03 lifecycle, WP04 review.
3. Inspect:

```bash
spec-kitty agent mission finalize-tasks --validate-only --mission --json
spec-kitty agent tasks status --mission --json
spec-kitty agent status validate --mission --json
cat kitty-specs//status.events.jsonl
cat kitty-specs//status.json
```

## Observed

- `wps.yaml`, `tasks.md`, and `lanes.json`: new 4-WP graph.
- Existing `WPCreated(WP02)` still names the old lifecycle prompt/path.
- Existing `WPCreated(WP03)` still names the old review prompt/path and dependencies.
- Existing `TasksCompleted` still has `wp_count: 3`.
- Only a new `WPCreated(WP04)` is appended; there is no task-definition supersession/refinalization event or new `TasksCompleted(wp_count=4)`.
- `status.json` reports `event_count: 0`, no WPs, and zero planned.
- `agent tasks status` reports four planned WPs.
- `agent status validate` passes.
- `migrate normalize-lifecycle --dry-run` offers only projection regeneration; no supported CLI repair represents the revised definitions.

## Expected

Before implementation begins, refinalization should atomically make the append-only authority represent the current graph, either through explicit supersession/refinalization events or another documented event-safe mechanism. Materialized status and task status should agree, and validation should reject stale definitions/counts or an empty projection.

## Safety requirement

Do not require hand-editing or truncating the append-only event log. A supported recovery command must preserve real transition history; a pre-implementation graph with bootstrap-only history should be recoverable deterministically.

Start with the listed finalize-tasks, tasks status, and status validate commands, then compare tasks.md, wps.yaml, lanes.json, status.events.jsonl, and status.json across the two-graph reproduction. Trace how lifecycle events and projections are generated and validated. Done means a supported recovery preserves transition history while the event authority, materialized status, task status, and validation agree on the revised graph.

Written by the indexing model from the issue text.