fix(wallet): discipline reservation liveness against a monotonic clock

[MichaelTaylor3d]

What changed

Reservation liveness (RESERVATION_TTL_MS / MAX_RESERVATION_HOLD_MS, #502/#525/#528) is judged
entirely on raw wall-clock readings. #528 (open, not yet merged) closes the case where the clock is
already wrong at the moment a reservation is FIRST written -- a self-contradiction between a row's
own two columns.

This closes the general form (#532): a wall clock that steps FORWARD while a reservation is
already live, mid-hold -- an NTP step correction, a VM pause/resume, an operator setting the
clock -- produces no such contradiction (the anchor is unchanged and the jumped reading looks like
an ordinary "now"). The very next liveness check reads the jump as elapsed time and can retire a
bundle's hold while it is still genuinely in flight, with no bound at all on how far forward
the step goes -- the #348/#497 double-spend direction, and strictly worse than #528's bounded
110-minute residual for a bad reading at write time.

ClockGovernor (new, crates/dig-wallet/src/sage/custody.rs) disciplines every
reservation-lifecycle "now" reading so it cannot advance, between two observations, faster than a
monotonic clock says real time has actually elapsed. WalletBackend now reads reservation
"now" through self.reservation_now_ms() (a thin wrapper sharing one Arc<Mutex<ClockGovernor>>
across every Clone, same pattern as custodied_public_keys) instead of calling
super::custody::now_ms() directly, at all 6 production call sites in the reservation lifecycle
(reservations_held, reserve_coins, reserve_pushed_bundle, get_pending_transactions,
spendable_coins, the CAT-send path).

The shape, and why

• Failure direction chosen: never release early, possibly release late. A forward wall-clock
  jump is absorbed rather than trusted -- the disciplined clock simply runs behind the wall clock
  and simply keeps pace with REAL elapsed time, until real time genuinely catches up, at which
  point it resumes tracking the wall clock exactly as before (no special unfreeze step; see
  the_clamp_releases_itself_once_real_time_catches_up). A backward wall-clock step is passed
  straight through UNCLAMPED -- it can only lengthen a hold, never shorten one, which is the safe
  direction A repushed bundle re-arms its reservation from now, so a retrying caller can hold coins indefinitely #502/fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528 already accept elsewhere. A governor that also clamped backward steps would
  be deciding a hold expired sooner than either clock claims -- exactly the failure this exists to
  close.
• Restart behaviour: the governor is process-local state, NOT persisted. A restart re-seeds it
  from the wall clock read at that moment (WalletBackend::new), so a clock that is already wrong
  AT BOOT is unguarded by this governor -- that is now_ms written directly into a fresh
  reservation, and remains fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528's write-time contradiction check's problem to catch, not this
  one's. This governor's job starts the instant after boot: a clock that reads fine at startup and
  jumps forward LATER, mid process lifetime, mid hold.
• Composes with fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528 without regressing it: fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528's contradiction predicate now reads the
  disciplined value instead of a raw wall-clock value at the same 6 call sites, so write-time and
  read-time observations stay on ONE continuous timeline (the same philosophy custody::now_ms's
  own doc comment already states for why there is one clock implementation, not two). This PR is
  independent of fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528 and does not depend on it merging first or in any order.
• Considered and rejected: swapping to a raw Instant-anchored deadline outright. Instant
  does not survive a process restart, and reservations ARE persisted across restarts, so a naive
  swap trades a clock-jump bug for a restart bug. The hybrid here keeps wall-clock persistence
  (unchanged DB schema, unchanged fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528 behaviour) and adds monotonic discipline only for the
  in-process, mid-lifetime observation gap that fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528 cannot see.

Tests

crates/dig-wallet/src/sage/custody.rs, mod tests (new), 5 tests, all passing:

• a_wall_clock_matching_real_time_passes_through_unclamped -- no clamp in the ordinary case.
• a_forward_jump_mid_hold_is_clamped_to_real_elapsed_time -- a 1-hour wall-clock jump with only
  100ms real elapsed is clamped to 100ms.
• a_backward_step_passes_through_unclamped -- confirms the deliberate asymmetry.
• the_clamp_releases_itself_once_real_time_catches_up -- proves this is not a freeze: tracking
  resumes automatically once real elapsed time reaches the jumped value.
• a_forward_clock_jump_mid_hold_no_longer_releases_a_live_reservation_early -- the money
  property, built from the REAL WalletDb::reserve_spend/prune_reservations API (no hand-placed
  row, same shape fix(wallet): bound a reservation deadline by the observing clock, not only by the first push's #528's own regression tests use): a bundle pushed at t=0, then a raw wall-clock
  jump that would read as past the reservation's deadline, does NOT release the coin when pruned
  through the governed clock; it releases only once real elapsed time actually reaches the TTL.

Every pure-decision test uses Instant::now() + Duration to construct two readings a known
distance apart -- exact and deterministic, no sleeping, no fake-clock trait needed.

Regression check -- every existing reservation-lifecycle test still passes after routing through
the governor (cargo test -p dig-wallet --lib reserv, run against the built WalletBackend
production paths, not just the DB layer):

running 19 tests
test result: ok. 19 passed; 0 failed; 0 ignored; 0 measured; 788 filtered out

cargo test -p dig-wallet --lib sage::custody::tests:

running 5 tests
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 802 filtered out

cargo clippy -p dig-wallet --lib -- -D warnings: clean, exit 0.
cargo check -p dig-wallet --lib: clean, exit 0.
rustfmt --check --edition 2021 on both touched files: clean, exit 0 (touched files only, not
cargo fmt --all).

Versioning -- NEEDS THE MAIN LANE

crates/dig-wallet/Cargo.toml is bumped 0.48.0 -> 0.48.1 (patch: internal bug fix, no API
change) and Cargo.lock is refreshed to match.

The root [workspace.package].version (the released dig-node binary version, currently
0.254.0) is intentionally left UNCHANGED. Per the dispatching brief: the minor field is at its
ceiling (package-version.sh caps minor <= 255) and another lane is fixing the version scheme
under #521/#522 right now. Requesting the correct next root version rather than inventing one --
the Check version increment CI job will fail on this PR until that number is supplied and
applied.

Status

DRAFT. Do not merge, do not undraft -- handing back to the main lane per the dispatch brief.

Closes #532