fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's

[MichaelTaylor3d]

Closes #525.

The defect

reserve_pushed_bundle (sage/rpc.rs:2325) reads the clock ONCE and writes submitted_at = now and expires_at = now + RESERVATION_TTL_MS. One reading far in the future (F) stores a deadline decades out, and nothing in the system could retire it:

• prune_reservations deletes on expires_at <= now, which never arrives.
• fix(wallet): bound the total hold a repushed bundle can keep on its inputs #505's upsert clamp is MAX(stored.expires_at, MIN(excluded.expires_at, stored.submitted_at + C)), so a later push under the corrected clock R computes MAX(F+T, MIN(R+T, F+C)) = F+T -- unchanged.
• coin_reservations.transaction_id REFERENCES pending_transactions ON DELETE CASCADE with foreign_keys(true), so the child row survives too, and reserved_coin_ids keeps excluding the coin from unreserved_unspent_coins for ever.
• reset_chain_cache does not delete either table and refuses while the row exists.

The coin is frozen permanently with no recovery available inside the product.

The fix -- repair at OBSERVATION

reserve_spend's upsert is unchanged. A write-time-only fix was rejected on the record: nothing re-pushes an accepted bundle unprompted, so it would leave the headline no-re-push freeze permanent.

WalletDb::prune_reservations now runs two repair UPDATEs before its two existing DELETEs, all four in ONE write-first transaction (the write lock is taken before any read -- the same ordering reserve_client_coins documents as what prevents a SQLITE_BUSY mis-mapped to Unavailable).

1. UPDATE pending_transactions SET submitted_at = now, expires_at = now + RESERVATION_TTL_MS WHERE expires_at > now + MAX_RESERVATION_HOLD_MS
2. UPDATE client_coin_reservations SET expires_at_ms = now + CLIENT_RESERVATION_MAX_TTL_MS WHERE expires_at_ms > now + MAX_RESERVATION_HOLD_MS

Return value unchanged: rows_affected of the first DELETE only. A repaired row is not a retired bundle, and folding it in would inflate a count callers read as in-flight spends.

Why the predicate is a self-contradiction check, not a heuristic

INSERT writes expires_at = now + T; the DO UPDATE clamp writes at most submitted_at + C. So every healthy row satisfies expires_at <= submitted_at + C, and with submitted_at <= now it satisfies expires_at <= now + C. Hence expires_at > now + C implies submitted_at > now -- the row claims to have been submitted after the present moment.

The false-fire floor

Let E = expires_at - submitted_at = min(e + T, C) where e is the row's age at the last push. The detector fires iff now < submitted_at + E - C, so a backwards clock step of d at age e fires iff d > max(C - T, e).

The minimum backwards step that can trip the repair on a legitimately created row is C - T = 50 minutes, and more for an older row. A claim that a 1 ms backwards step trips an at-cap row is false: an at-cap row is ~50 minutes old, so it needs d > 50 min too.

The genuine cost, stated not argued away

Past that floor a live bundle's row IS re-anchored and gets only T more from the repair instant, where the unrepaired code would have held it until the clock caught up (d + E - e longer). So a backwards step exceeding MAX_RESERVATION_HOLD_MS - RESERVATION_TTL_MS can return a still-live bundle's inputs after one further TTL instead of on clock recovery. That is a real move toward the #348/#497 double-spend direction, bounded by a gross (>50 min) clock anomaly, and accepted because the alternative it replaces is a permanent, in-product-unrecoverable freeze -- the failure RESERVATION_TTL_MS' own doc and SPEC.md 18.9a both name as the worse one. This fix does not "never release anything early".

The four decisions inside the shape

1. Grant now + T, not now + C -- precisely what an honest push at now would have written. now + C would hand a repaired row six times a healthy row's first hold.
2. submitted_at is re-anchored, and this is not optional. Left at F, stored.submitted_at + C = F + C, so A repushed bundle re-arms its reservation from now, so a retrying caller can hold coins indefinitely #502's cap clause stops binding on that row for ever and a retrying caller renews the hold indefinitely -- resurrecting the A repushed bundle re-arms its reservation from now, so a retrying caller can hold coins indefinitely #502 lockout. This is not a regression of A repushed bundle re-arms its reservation from now, so a retrying caller can hold coins indefinitely #502's stable-anchor rule: that rule keeps the column out of DO UPDATE SET so a CALLER cannot move the anchor. This write is not a caller; it is the row's owner replacing a value the system has proven impossible with one from the currently trusted clock. Stated in the doc comment.
3. Both detectors use MAX_RESERVATION_HOLD_MS, including the client one. Keying the client detector on its own 10-minute ceiling would let a ~5-minute backwards step re-clamp a healthy client hold and reopen the cross-process selection window dig_ecosystem#3127 closes. One hour is the longest hold of any kind this wallet grants. Pinned by a const _: () = assert!(CLIENT_RESERVATION_MAX_TTL_MS <= MAX_RESERVATION_HOLD_MS, ...) beside the constant, so the detector cannot silently become unsound if either moves.
4. The client repair grants now + CLIENT_RESERVATION_MAX_TTL_MS, not now + T: there is no submitted_at column and the caller's requested TTL is unrecoverable, so it grants the ceiling a caller could legitimately have asked for. That errs long, the safe direction for a build-window hold. The asymmetry is stated in the comment.

Blast radius checked

prune_reservations callers, via grep (gitnexus indexes are stale by construction here -- commitsBehind on dig-node is in the hundreds and points at the primary checkout, so impact would return a false-safe zero):

• rpc.rs:875, 893, 2961, 3228, 3695 -- all already prune before a reservation-sensitive read, and all are unaffected: the signature, the return value's meaning, and the two DELETE predicates are unchanged.
• rpc.rs:1198 (reset_coin_db) -- the one entry point that did NOT prune, now does. Without it a user whose first action after correcting the clock is a reset gets ResetRefusal::SpendInFlight telling them to wait, and waiting alone triggers no prune. SpendInFlight's counting predicate (db.rs:3005) and its message text are deliberately unchanged: excluding contradicted rows from the count would let a reset wipe coins beneath a bundle that may genuinely be in a mempool, and the sentence "Wait for them to confirm or expire, then retry" is false today but becomes TRUE under this fix.
• Test-only callers in db.rs.

Risk: MEDIUM. It is custody-adjacent (it decides when a coin returns to selection) but it strictly shrinks an unbounded hold to a bounded one, and its one early-release path is the >50-minute-clock-anomaly case stated above.

Evidence

RED, before the fix (cargo test -p dig-wallet --lib, real counts, not a zero-match run):

test sage::db::tests::the_clock_contradiction_repair_re_anchors_submitted_at_so_the_cap_still_binds ... FAILED
test sage::db::tests::the_clock_contradiction_repair_grants_one_fresh_ttl_not_the_maximum_hold ... FAILED
test sage::db::tests::the_clock_contradiction_detector_fires_strictly_past_the_maximum_hold ... FAILED
test result: FAILED. 0 passed; 3 failed; 0 ignored; 0 measured; 798 filtered out

test sage::db::tests::a_reservation_anchored_to_a_far_future_clock_stops_freezing_its_coin_for_ever ... FAILED
test sage::db::tests::a_client_hold_written_under_a_far_future_clock_is_repaired_and_then_lapses ... FAILED
test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 799 filtered out

The headline failure line: assertion left == right failed: one TTL after the repair the coin returns to selection; before this fix it never did.

GREEN, after: test result: ok. 800 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out (baseline at f0a9726 was 794 passed / 1 ignored; +6 new tests).

cargo fmt --check on the two touched files only: CLEAN. No workspace-wide cargo fmt --all.

Tests added (6)

test	pins
a_reservation_anchored_to_a_far_future_clock_stops_freezing_its_coin_for_ever	the headline freeze, asserted on unreserved_unspent_coins(None) -- the selection surface where the money is frozen, not a pending_transactions row count one layer below the decision
the_clock_contradiction_repair_grants_one_fresh_ttl_not_the_maximum_hold	the AMOUNT of the grant, not just its existence
the_clock_contradiction_repair_re_anchors_submitted_at_so_the_cap_still_binds	the re-anchor: a re-push at corrected + 5.5T must land on corrected + C; without the re-anchor it lands on corrected + 6.5T
a_client_hold_written_under_a_far_future_clock_is_repaired_and_then_lapses	the client arm
a_one_millisecond_backwards_clock_step_repairs_nothing	no-false-positive guard (a)
the_clock_contradiction_detector_fires_strictly_past_the_maximum_hold	no-false-positive guard (b): both sides of the exact bound -- at now + C untouched, at now + C + 1 repaired

Mutation table (each run in full, then reverted)

mutation	result	named tests that went red
1. delete the UPDATE pending_transactions statement entirely	796 passed; 4 failed	a_reservation_anchored_to_a_far_future_clock_stops_freezing_its_coin_for_ever, the_clock_contradiction_repair_grants_one_fresh_ttl_not_the_maximum_hold, the_clock_contradiction_repair_re_anchors_submitted_at_so_the_cap_still_binds, the_clock_contradiction_detector_fires_strictly_past_the_maximum_hold
2. grant now + MAX_RESERVATION_HOLD_MS instead of now + RESERVATION_TTL_MS	797 passed; 3 failed	..._grants_one_fresh_ttl_not_the_maximum_hold, a_reservation_anchored_to_a_far_future_clock_..., ..._detector_fires_strictly_past_the_maximum_hold
3. drop SET submitted_at = ?now	799 passed; 1 failed	the_clock_contradiction_repair_re_anchors_submitted_at_so_the_cap_still_binds (uniquely)

Mutation 3 localises to exactly one test, which is the one it must. Mutations 1 and 2 overlap, as expected: mutation 1 removes the whole repair, so every test that observes any part of it goes red; mutation 2 is the strictly narrower "amount" mutation and is the one distinguished by ..._grants_one_fresh_ttl_....

Also in this PR

• Corrected the existing revert-proof fixture a_repush_under_a_clock_that_stepped_backwards_never_shortens_a_live_hold. Its third push passed submitted_at = first while moving only expires_at backwards -- a state reserve_pushed_bundle cannot produce, since it writes both from one clock read. It is now the production-shaped submitted_at = first - 60_000, expires_at = first - 60_000 + T (well under the 50-minute detector floor, so the row must be untouched by the new repair). Its existing assertion row.expires_at == extended_at + RESERVATION_TTL_MS still holds unchanged, now for a reachable state.
• SPEC.md 18.9a ("In-flight coin reservation", the reservation-contract section -- note the file re-uses the number 18.9a at two other points for the offer/DID-mint suite; that pre-existing collision was NOT touched or renumbered): a normative statement that a recorded deadline exceeding the current instant by more than MAX_RESERVATION_HOLD_MS MUST be treated as contradicting the clock, MUST be re-anchored to the current instant with a fresh lifetime before any expiry is evaluated (and the client hold re-granted its own maximum), so a reservation is never held beyond the maximum hold measured from an instant the node has observed.

Version in Cargo.toml is 0.252.31, unchanged as instructed.

Deliberately NOT done -- reported, not fixed

1. Forward-jump early release. prune_reservations frees LIVE inputs when the clock jumps forward: the DELETE fires on expires_at <= now with no lower bound, so a forward jump past a live deadline retires a bundle that may still be in a mempool. On main today, unchanged by this fix, and a separate defect in the sec(reservation): gated on an untrusted 'accepted' — the under-claim direction fails OPEN into the double-select window #348/fix(wallet): a peer-local refusal must not free inputs another destination may hold #497 double-select direction.
2. Reservation lifetimes are on wall-clock custody::now_ms(). That is the actual root cause of both this ticket and (1): a monotonic anchor for elapsed time, with wall-clock kept only for display, would make both unreachable. Much larger change; not started.
3. reserved_coin_ids' clockless raw read -- over-reserves by design, safe direction, untouched.
4. The sawtooth and timelock limitations on MAX_RESERVATION_HOLD_MS' doc -- documented, intended, unaffected.

Not merged, not undrafted, no review requested -- left DRAFT for the gate round.

[MichaelTaylor3d]

loop-security interim — IN PROGRESS, not the verdict

Audited head: 2edd6241ca170aa2382d75f5a03e6610646cd502 (resolved from gh pr view 528 --json headRefOid, matches the brief). Read-only; no shared checkout mutated.

Q1 — clock provenance on every prune_reservations path: CLEAN

Traced all six production call sites. None takes the instant from a caller, a peer, or an RPC parameter.

site	how now_ms is obtained	verdict
sage/rpc.rs:875 (reservations_held)	let now_ms = custody::now_ms() as i64 local	node clock
sage/rpc.rs:893 (reserve_coins)	let now_ms = custody::now_ms() as i64 local	node clock
sage/rpc.rs:1205 (reset_coin_db, NEW)	parameter now_ms: i64 — see below	node clock at the only caller
sage/rpc.rs:2969 (get_pending_transactions)	custody::now_ms() inline	node clock
sage/rpc.rs:3236 (spendable_coins)	custody::now_ms() inline	node clock
sage/rpc.rs:3703 (CAT send selection)	custody::now_ms() inline	node clock

The new site is the only one worth argument, because reset_coin_db(&self, now_ms: i64) is pub and takes the instant as an argument. Its sole production caller is dig-node-service/src/control.rs:2612, and that handler computes the instant itself at control.rs:2603-2609 from SystemTime::now().duration_since(UNIX_EPOCH) — never from params. The reasoning the brief asked me to check for is present and explicit at control.rs:2600-2602:

The node's own clock. A caller-supplied instant would be a lapse oracle: a far-future value makes every live spend reservation read as expired, which is exactly the guard being asked to stand down.

So the lapse-oracle reasoning documented on held_reservations was applied on this path, including the new one. custody::now_ms() (sage/custody.rs:441) is a plain SystemTime::now() read with no caller input.

No remote reservation-release primitive exists via the clock. A caller cannot pass an instant that deletes holds, and cannot pass one that trips the repair.

Still working: repair weaponisation without the clock (Q2), DoS/index/row-bounds (Q3), transaction+SQLITE_BUSY→Unavailable (Q4), saturation (Q5), the anchor-move vs #502 (Q6), reset_chain_cache ordering (Q7), and the submitted_at truthfulness question (Q8) — which is the one I expect to take longest.

[MichaelTaylor3d]

Correctness gate — PASS

Head reviewed: 2edd6241ca170aa2382d75f5a03e6610646cd502 (resolved from gh pr view 528 --json headRefOid; matches the brief).
Diff reviewed: git diff 15341ee..HEAD — SPEC.md, crates/dig-wallet/src/sage/db.rs, crates/dig-wallet/src/sage/rpc.rs.

Measured myself: cargo test -p dig-wallet --lib -> 800 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out, exit 0. Matches the brief's head figure. Non-zero test count, so this is a real run and not a filtered-to-nothing green.

1. The soundness argument is TRUE

Every production writer of pending_transactions.submitted_at / .expires_at was enumerated:

• INSERT arm, db.rs:2801 — the only production caller is reserve_pushed_bundle (rpc.rs:2350, via reserve_spend; every other reserve_spend( hit in the crate is a test). It writes submitted_at = now_c and expires_at = now_c + RESERVATION_TTL_MS, so expires_at = submitted_at + TTL <= submitted_at + CAP.
• DO UPDATE arm, db.rs:2805-2808 — MAX(stored.expires_at, MIN(excluded.expires_at, stored.submitted_at + CAP)). submitted_at is not in SET, and both MAX operands are <= submitted_at + CAP by induction. Invariant preserved.
• The new repair UPDATE, db.rs:2924 — writes submitted_at = now, expires_at = now + TTL. Invariant preserved, and idempotent: a repaired row can never re-trip the detector.

No other statement in the crate writes either column. So expires_at <= submitted_at + CAP holds for every reachable row, and expires_at > now + CAP implies submitted_at > now. The doc comment's claim is correct. No false-positive class from a healthy writer.

2. The 50-minute floor is CONFIRMED (the shorthand formula is conservative, not wrong)

With E = expires_at - submitted_at = min(e_p + TTL, CAP), where e_p is the row age at its last push, the detector fires iff now < submitted_at + E - CAP. For a backwards step d on a row of true age e, that is exactly

d > e + max(CAP - e_p - TTL, 0)

• Never-re-pushed row (e_p = 0, E = TTL): threshold e + 50 min.
• At-cap row (E = CAP): threshold e, and e >= e_p >= CAP - TTL = 50 min.

The infimum over all reachable rows is CAP - TTL = 50 minutes, attained as e -> 0. The load-bearing number in the money argument is correct, and the earlier draft's "1 ms step trips an at-cap row" is refuted: an at-cap row needs d > e >= 50 min.

The comment's shorthand d > max(CAP - TTL, e) is a lower bound on the true threshold (exact in the at-cap case, understated for a young never-re-pushed row) — conservative in the safe direction. Non-gating; note (a) below.

3. The client-hold asymmetry is correct and correctly guarded

Healthy client row: expires_at_ms = now_w + ttl, with ttl clamped to <= CLIENT_RESERVATION_MAX_TTL_MS in reserve_client_coins. A detector at now + CAP therefore needs now_w > now + CAP - ttl >= now + 50 min — the same 50-minute floor as the bundle table, which is exactly the justification given. Keying on the table's own 10-minute ceiling would indeed have produced a ~5-minute false-fire floor.

The const _: () = assert!(CLIENT_RESERVATION_MAX_TTL_MS <= MAX_RESERVATION_HOLD_MS) at db.rs:4440 prevents precisely the unsoundness it names: raise the client ceiling above CAP and healthy client rows become detectable. The guard is load-bearing and correctly stated.

Granting the ceiling rather than the (unrecoverable) requested TTL errs long; for a build-window hold that is the safe direction, as argued. Post-repair expires = now + CLIENT_MAX <= now + CAP, so the repair is idempotent here too.

4. The transaction change is sound

• Return value is still Ok(n) where n is rows_affected() of the first DELETE only (db.rs:2958-2969, :2991). The client DELETE result is discarded, unchanged. Read, not assumed.
• A repaired row cannot be deleted by the DELETE below it: after repair expires_at = now + TTL > now, so expires_at <= ?now is false. It can still be deleted by the spent-coin cascade arm, which is correct.
• Write-first ordering: self.pool.begin() is DEFERRED, and the first statement in the transaction is now an UPDATE, so the write lock is taken before anything else. prune_reservations contains no reads at all, so the read-then-write shape reserve_client_coins warns about at db.rs:4615-4619 is unreachable here.
• The adjacent risk the brief did not raise: reserve_coins (rpc.rs:893) propagates prune's sqlx::Error through From<sqlx::Error> for ReserveClientCoinsError (db.rs:4567) into Unavailable. So prune's lock window does feed that mapping — but it did before this PR too (two autocommit writes), sqlx's default busy_timeout is 5 s, and four statements in one transaction is one lock acquisition instead of two. No regression.

5. The tests assert at the decision, and the corrected one is right

• a_reservation_anchored_to_a_far_future_clock_stops_freezing_its_coin_for_ever asserts on unreserved_unspent_coins — the selection surface, not a raw row count. With the repair reverted, expires_at stays decades out, the DELETE never fires, and the second assertion goes red. Not vacuous.
• Its start state (submitted_at = F, expires_at = F + TTL) is exactly what reserve_pushed_bundle writes from one clock reading. Reachable.
• The boundary test's at-bound row (expires_at = submitted_at + CAP) is reachable via the DO UPDATE clamp, which leaves submitted_at alone and pins expires_at at submitted_at + CAP. past-bound is deliberately unreachable and is the negative probe. Correct pairing.
• The #505 revert-proof correction (a_repush_under_a_clock_that_stepped_backwards_never_shortens_a_live_hold) is right: moving both columns by step_back is the only production-reachable shape, since reserve_pushed_bundle reads the clock once. step_back = 60_000 is far under the 50-minute floor, so the repair provably cannot fire and the test still exercises the clamp alone — its original assertion (expires_at unchanged) still holds for the now-reachable state.

6. Mutation claim — analytically confirmed, NOT executed

I did not run the mutation, and say so rather than implying otherwise: the tree is shared read-only and cutting a worktree for one compile was not worth the spend. Analytically, dropping SET submitted_at = ?now leaves submitted_at = F, so MIN(late + TTL, F + CAP) = late + TTL and MAX(corrected + TTL, late + TTL) = late + TTL, which is not corrected + MAX_RESERVATION_HOLD_MS — so ..._re_anchors_submitted_at_so_the_cap_still_binds goes red. The other five are unaffected: tests 1 and 2 depend only on expires_at, and tests 4-6 never touch that column. The unique-localisation claim holds.

7. SPEC.md

The insert lands at SPEC.md:5796-5808, inside the 18.9a In-flight coin reservation section opening at :5711. The second 18.9a at :5869 (offer suite) is pre-existing duplication and is untouched — nothing renumbered.

The normative text is true of the shipped code: repair before expiry evaluation (db.rs:2924 precedes :2958), client hold re-granted its own maximum (:2949), and the "never hold beyond MAX_RESERVATION_HOLD_MS from an observed instant" clause is discharged because the repaired row is anchored at now and the DO UPDATE cap binds from that anchor. No overclaim found.

8. rpc.rs:1198

reset_chain_cache's refusal counts pending_transactions WHERE expires_at > ?now (db.rs:3086). Pruning first repairs the poisoned row to now + TTL, which still refuses — but now refuses for a bounded time, so the message's "wait for them to confirm or expire" becomes true. No re-entrancy: prune commits its own transaction before reset_chain_cache opens one; no nesting, no lock held across the call. No ordering problem.

9. Beautiful-code gate

Comments are long but every paragraph carries a WHY, and I found no claim the code does not do. Names are intent-revealing; the test names state properties rather than outcomes.

---

Non-gating notes (recorded here, deliberately NOT as inline threads, so they cannot bar the merge)

(a) db.rs around 2900 — the false-fire shorthand d > max(CAP - TTL, e) is a lower bound, not the exact threshold; the exact one is d > e + max(CAP - e_p - TTL, 0). The stated 50-minute minimum is correct either way. Worth a word if the file is touched again; not worth a round trip.

(b) db.rs:2865-2869 — "A deferred transaction that read first would reintroduce exactly that" describes a shape prune_reservations cannot have, since it performs no reads. The ordering property asserted is true and the code satisfies it; the rationale is borrowed from reserve_client_coins, where it does bite.

(c) test ..._re_anchors_submitted_at_so_the_cap_still_binds passes far_forward as the re-push's submitted_at. It is inert (the DO UPDATE arm ignores that column) and the assertion is unaffected, but late would be the production-faithful value.

None of the three changes a behaviour, a bound, or a money outcome.

Verdict: PASS. No gating findings, so this gate leaves no open threads. The orchestrator owns the undraft and the merge; this review does not undraft, and the tree was not modified.

[MichaelTaylor3d]

loop-security interim 2 — IN PROGRESS, not the verdict

Head 2edd6241ca170aa2382d75f5a03e6610646cd502.

Q2 — can the repair be trip'd without touching the clock? NO. Clean.

Neither table lets a caller push a stored deadline past now + MAX_RESERVATION_HOLD_MS:

• pending_transactions: the only production writer is reserve_pushed_bundle (sage/rpc.rs:2333-2351). It reads custody::now_ms() ONCE and writes submitted_at: now, expires_at: now + RESERVATION_TTL_MS. The caller supplies the bundle — hence transaction_id and reserved_coin_ids — but neither timestamp. Max reachable deadline now + 600_000 < now + 3_600_000.
• client_coin_reservations: reserve_client_coins (sage/db.rs:4638-4642) takes a caller TTL but .clamp(1, CLIENT_RESERVATION_MAX_TTL_MS) it, so expires_at_ms <= now + 600_000. The new const _: () = assert!(CLIENT_RESERVATION_MAX_TTL_MS <= MAX_RESERVATION_HOLD_MS) at db.rs:4441 pins that relationship at compile time — a real guard, not vacuous.

The repair is also idempotent, which I checked because a re-firing repair would be a hold-renewal primitive. It grants now + 600_000 against a threshold of now + 3_600_000, so a repaired row cannot satisfy the predicate on the next prune. It fires once per row per clock excursion.

"Evade repair by staying just under" gains nothing: staying under the threshold is the healthy state, and the hold is still bounded by the expires_at <= now DELETE and #502's cap.

---

FINDING 1 — the repair DESTROYS a live hold on any backwards clock step over ~50 min, and the release is at clock RECOVERY, not "one TTL later". Severity MEDIUM, defense-in-depth-with-a-caveat — see the ask at the end.

sage/db.rs:2921-2929. The trade is disclosed in the comment at db.rs:2905-2919, and I agree with the direction of the decision — a permanent unrecoverable freeze is worse. But the disclosure's own sizing is wrong in the unsafe direction, and that is what I want on the record before this merges.

The comment says:

a backwards step exceeding 50 minutes can return a still-live bundle's inputs one TTL later instead of on clock recovery

Measured, that is backwards. The repair writes expires_at = now + TTL where now is the stepped-back clock, so the new deadline is in the PAST in real time. On clock recovery the very next prune's DELETE ... WHERE expires_at <= ? matches it immediately:

backwards step	repair fires	repaired expires_at	deleted at clock recovery
0.5 h	no	unchanged	no
0.9 h	yes	now-0.9h + 10min	yes, immediately
5 h	yes	now-5h + 10min	yes, immediately
13 h	yes	now-13h + 10min	yes, immediately

So the real behaviour is "released on clock recovery", which is the phrase the comment uses for the safe alternative. A reader sizing this risk will read "one TTL" as ten minutes of remaining protection that does not exist.

Concrete scenario, no attacker required. pending_transactions is persistent across restarts. Node holds a live reservation for a bundle in the mempool → machine reboots → RTC reads hours off (dual-boot Windows/Linux localtime-vs-UTC RTC is the classic case, offset up to 13 h; a dead CMOS battery is another) → node starts, any wallet read prunes (spendable_coins, get_pending_transactions, reservations_held, reserve_coins, the CAT send path, and now reset_coin_db) → row is repaired → NTP corrects the clock → next prune DELETEs the row while the bundle is still live in the mempool → its inputs return to unreserved_unspent_coins → a second spend can be built on them. That is the #348/#497 direction.

Before this diff the same excursion was harmless: the row kept its true deadline through the excursion and expired on time.

Cheap mitigation that keeps the whole benefit. The detector's soundness argument only needs the threshold to be an upper bound no healthy row can exceed — MAX_RESERVATION_HOLD_MS is the smallest sound choice, which maximises false-fire exposure. #525's actual failure is a deadline decades out. A threshold well past any plausible clock excursion (e.g. now + 24 h, or an explicit CLOCK_CONTRADICTION_MARGIN_MS) still repairs the freeze this PR exists to fix while putting the false-fire floor above the RTC/timezone class entirely. It stays sound (strictly fewer fires), and the const assert just re-points at the new threshold.

I am not gating on this by itself — the decision to prefer a bounded release over a permanent freeze is defensible and is the ticket's whole point. What I do want before merge is the comment and SPEC.md corrected, because right now they understate a money-direction risk, and a future reader will size it from that sentence.

Still open: Q3 DoS quantification, Q4 SQLITE_BUSY→Unavailable, Q5 saturation, Q7 reset ordering, Q8 submitted_at honesty.

[MichaelTaylor3d]

Adversarial gate: NOT-REFUTED, with one finding that must be fixed before merge

Independent Opus context, prompted to refute. It could not construct a permanent freeze, and could
not find a cheaper early-release than the >50-minute backwards step already conceded on the record.
Suite independently re-measured at 2edd624: 800 passed, 0 failed, 1 ignored, 0 filtered out.

FINDING (gating, doc-only): the normative sentence this PR adds to SPEC.md is FALSE

"A node MUST therefore never hold a reservation beyond MAX_RESERVATION_HOLD_MS measured from an
instant the node has actually observed."

A forward clock glitch at first push evades the detector by construction, and the true bound is
2*CAP - TTL = 110 minutes, not 60.

To evade the detector at the first corrected observation a row needs expires_at <= now + CAP.
INSERT writes expires_at = submitted_at + TTL, so evasion holds exactly while the anchor is at
most CAP - TTL = 50 minutes ahead of true time. Take that maximum:

step	clock reads	call	row
1	3_000_000 (glitch, +50 min; true time 0)	first push	submitted_at=3_000_000, expires_at=3_600_000
2	0 (corrected)	prune_reservations(0)	detector 3_600_000 > 0 + 3_600_000 is false - not repaired, not deleted
3	true t, rising	a retrying caller re-pushes	expires_at = t + TTL, so expires_at > t + CAP is never true
4	t = 6_000_000	cap clause binds	expires_at stops at submitted_at + CAP = 6_600_000

Released at observed t = 6_600_000 = 110 minutes. The evasion window and the false-fire floor
are the same constant CAP - TTL seen from two sides.

The code is not wrong; the sentence is. This 110-minute ceiling is #505's cap behaviour under a
forward glitch and predates this PR. What this PR does is assert a tighter bound than either PR
delivers - a normative claim born false in the commit that writes it, which is exactly the class
#505's own body flagged when it noted the original defect was derivable from the spec.

Remedy: state the true bound and name the forward-glitch residue explicitly, the same way the
backwards-step cost is already on the record. No code change to the repair.

Two secondary findings, both accepted

• Missing drift guard. There is a const _: () = assert! pinning CLIENT_RESERVATION_MAX_TTL_MS <= MAX_RESERVATION_HOLD_MS, but none pinning RESERVATION_TTL_MS <= MAX_RESERVATION_HOLD_MS. If
  the TTL ever exceeded the cap, a repaired row would satisfy the detector again on the next prune
  and re-anchor for ever - an unbounded freeze produced by the repair itself. Structurally
  impossible today (CAP = 6 * TTL), which is why it is a note and not a refutation; but if one
  constant pair is worth a compile-time guard, so is the pair that would turn the repair into a loop.
• the_clock_contradiction_detector_fires_strictly_past_the_maximum_hold uses an unreachable
  row. Its past-bound fixture is submitted_at = now, expires_at = now + CAP + 1; production's
  INSERT always writes submitted_at + TTL and the clamp never exceeds submitted_at + CAP, so no
  writer can produce it. It is a predicate-boundary test wearing a production test's clothes - and a
  reachable equivalent (submitted_at = now + X, expires_at = submitted_at + TTL) would have
  surfaced the 110-minute finding above. The correctness gate read this row as reachable; it is not.

Attacks that failed, for the record

The induction survives an upgrade (both deadline columns are NOT NULL with no DEFAULT, there are
exactly two writers, no INSERT OR REPLACE, no migration, and pre-#505 rows satisfy
expires_at <= submitted_at + TTL anyway). The 50-minute floor re-derived without assuming the
span formula and holds in every branch, including the client table. No wire-reachable clock reaches
the repair: every prune_reservations caller takes custody::now_ms(), and the one parameterised
entry (reset_coin_db) is called only by control.rs, which reads the clock itself. No growing
fixed point in repair/re-push composition. No interleaving found that loses a hold or double-counts
rows_affected. A repaired row still counts toward ResetRefusal::SpendInFlight, so prune-first
cannot let a reset slip past a live hold.