Rail-17 withdrawal attestation cadence — the 7-day TTL needs a visible refresh habit

[eaitbrahim]

The 2026-08-15 status review records that a valid DCA signal on 2026-08-14 was vetoed by rail 17 because the withdrawal-capability attestation had expired — the one rule that trades, blocked by an expired attestation. As of 2026-08-17 the attestation is stale in BOTH deployments (paper attested 2026-07-21, live 2026-08-03, against a 7-day TTL), so rail 17 is currently halting all entries everywhere.

Re-attestation (keel withdrawals attest --enabled, typed confirmation) is deliberately a human terminal action — a scheduled job must not be able to release a §65.4 halt — so the fix here is cadence, not automation:

• Operator-runbook note: the 7-day TTL needs a weekly refresh habit (or a calendar reminder); name the consequence of missing it (rail 17 fails closed on unknown → live DCA buys vetoed).
• Consider (decision, not default): whether keel status should surface days-to-expiry on the withdrawal attestation the way it surfaces data freshness, so staleness is visible before it vetoes rather than after. If declined, record why in this issue.