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>
Implements task ID integrity detection across the stack (FN-4192): a new `task-id-integrity` module in core provides detector logic wired into the store, integrity health is surfaced via the dashboard API and legacy endpoint, and a banner component surfaces alerts in the UI — backed by comprehensive
Fusion-Task-Id: FN-4192
