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/core/src/__tests__/task-id-integrity.test.ts

@@ -99,7 +99,7 @@ describe("detectTaskIdIntegrityAnomalies", () => {
     );
   });
 
-  it("detects committed reservations that target existing task IDs", () => {
+  it("does not flag committed reservations that point at existing task IDs (the happy-path steady state)", () => {
     const db = createDb();
     const now = new Date().toISOString();
     insertTask(db, "FN-103");
@@ -124,13 +124,8 @@ describe("detectTaskIdIntegrityAnomalies", () => {
 
     const report = detectTaskIdIntegrityAnomalies(db);
 
-    expect(report.anomalies).toContainEqual(
-      expect.objectContaining({
-        kind: "committed_reservation_for_existing_id",
-        prefix: "FN",
-        affectedIds: ["FN-103"],
-      }),
-    );
+    expect(report.status).toBe("ok");
+    expect(report.anomalies).toEqual([]);
   });
 
   it("detects active task rows whose prefix is outside distributed state", () => {