Decouple PASSIVE/TRUNCATE WAL checkpoint cadences

[srhoods]

Summary

• A 6-hour, 10-agent re-test of the coupled PASSIVE/TRUNCATE split (one ticker, TRUNCATE riding every 10th PASSIVE tick, 20s/200s effective) found PASSIVE's own median s.mu hold (3.4s, 377 calls) running higher than TRUNCATE's (2.95s, 41 calls) — backwards from what the split was for, since PASSIVE needs no exclusive lock at all.
• At a 20s interval there's very little real WAL content per call, so PASSIVE's hold was dominated by the same fixed per-call overhead (lock dispatch, the PRAGMA itself) that limited TRUNCATE before the split existed — just paid 9x as often as necessary, because the coupled ticker forced PASSIVE's cadence to always be truncateEvery/ratio.
• RunWALCheckpoint now runs PASSIVE and TRUNCATE on two independent tickers instead of one ticker with a tick-count ratio, so each cadence can be tuned without moving the other. PASSIVE widened to 60s to accumulate more real backlog per call; TRUNCATE's already-working ~200s cadence is left alone.
• Store.WALCheckpoint (the public, always-TRUNCATE entrypoint) is unchanged.

Test plan

• go build ./..., go vet ./..., gofmt -l . all clean (the earlier PR Shrink WALCheckpoint's interval: TRUNCATE was holding s.mu for tens of seconds #64 push missed a gofmt issue — checked locally this time)
• go test ./... full coordinator suite green
• go test -race -short ./internal/passctrl/... ./internal/store/... ./internal/agentsrv/... clean
• TestRunWALCheckpointTruncatesOnItsOwnCadence (replaces the tick-count-coupled version) verified to fail when the two tickers are collapsed back into one — 10/10 stable runs otherwise

🤖 Generated with Claude Code

https://claude.ai/code/session_01PsdNZLfmAFrMX2VUtkLtmm