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/src/__tests__/server.test.ts

@@ -440,10 +440,10 @@ describe("createServer health and headless mode", () => {
         checkedAt: "2026-05-12T11:00:00.000Z",
         anomalies: [
           {
-            kind: "committed_reservation_for_existing_id",
+            kind: "duplicate_active_id",
             prefix: "FN",
             affectedIds: ["FN-103"],
-            details: "reservation collision",
+            details: "duplicate row",
           },
         ],
       }),
@@ -468,10 +468,10 @@ describe("createServer health and headless mode", () => {
         checkedAt: "2026-05-12T11:00:00.000Z",
         anomalies: [
           {
-            kind: "committed_reservation_for_existing_id",
+            kind: "duplicate_active_id",
             prefix: "FN",
             affectedIds: ["FN-103"],
-            details: "reservation collision",
+            details: "duplicate row",
           },
         ],
         recommendedAction: