fix(spine): the platform's only CRITICAL self-finding was permanent and benign #5495

The finding

bun scripts/selfcheck.ts reported critical=1 on every run, holding the self-score at 75/100. Production logged it every tick:

[autopilot] selfcheck: score=75 critical=1 high=2 new=0 fixed=0
[autopilot] selfcheck: 1 CRITICAL finding(s) — see /admin/selfcheck

It is raw-sql-interpolation at spine-alert-fanout.ts:123:

interval '${sql.raw(String(SPIKE_WINDOW_MINUTES))} minutes'

Why it was never a vulnerability — and why it still mattered

SPIKE_WINDOW_MINUTES is a module constant (export const SPIKE_WINDOW_MINUTES = 10), never user input. There is no injection path.

But new=0 means it had been reported unchanged for as long as the rule has existed, and that is the damage. A CRITICAL that is permanently red and permanently harmless is worse than no signal at all: it caps the score, it fires an alert line every tick, and it teaches every reader to scroll past the one severity the rule exists to make them stop at. The next genuinely-injectable interpolation would have landed in a channel nobody reads.

The fix

now() - make_interval(mins => ${SPIKE_WINDOW_MINUTES})

Binds the window as a query parameter and removes sql.raw from the path entirely. Same semantics, same plan shape.

Cleared by construction, not by a selfcheck-ignore marker. A suppression would leave the rule blind to a real interpolation appearing on this line later — and selfcheck already reports two dead-suppression findings (github-issue-import.ts:526,628), which is the same mistake one step further along: a marker that outlived its finding and now reads as a considered decision.

Verification

spine-alert-fanout + admin-spine: 11 pass. tsc --noEmit clean.

Remaining selfcheck findings (not in this PR)

high 2 — gate.ts:566 unvalidated-git-ref, synthetic-journeys.ts:189 swallowed-rejection. Both worth their own look; the git-ref one especially.