fix: drop false-positive committed_reservation_for_existing_id integrity check

The rule flagged every committed reservation pointing at an existing task ID
as an anomaly, but that's the happy-path steady state — reservations
transition to `committed` immediately after the task row is inserted, so a
committed reservation is always expected to reference an existing task. On
any node with task history, the dashboard banner fired with hundreds of
"affected" IDs and the store emitted a spurious `[task-id-integrity] anomaly
detected` error log.

Removes the rule, its type/label/reader, and updates tests (core regression
guard now asserts committed reservations don't trigger anomalies; dashboard
server-test fixtures use a still-valid anomaly kind).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

packages/dashboard/app/components/TaskIdIntegrityBanner.tsx

@@ -14,7 +14,6 @@ const ANOMALY_LABELS: Record<TaskIdIntegrityReport["anomalies"][number]["kind"],
   duplicate_active_id: "Duplicate active task ID",
   id_in_active_and_archived: "Task ID present in active and archived storage",
   next_sequence_at_or_below_used: "Allocator next sequence overlaps an existing task ID",
-  committed_reservation_for_existing_id: "Committed reservation still points at an existing task ID",
   task_row_outside_known_prefix: "Task row uses a prefix outside allocator state",
 };