fix: bind SwapConfirm to reserve-time commitment (#61)

[Rene0422]

Summary

• handle_swap_confirm now reads the miner's commitment as of the reservation creation block, not live, so reserve and confirm are bound to the same swap terms.
• Reservation block is derived from on-chain state as reserved_until − RESERVATION_TTL_BLOCKS − extension_count × MAX_EXTENSION_BLOCKS — exact for un-extended reservations, a safe lower bound when extensions have fired.
• load_swap_commitment gains an optional block arg; handle_swap_reserve is unchanged (still reads live, which is correct at reserve time).
• ContractError on the new get_reservation_extension_count read falls back to extension_count = 0 so a transient RPC failure doesn't break confirm.

Closes #61.

Why this matters

Before this fix, a miner could republish their commitment between a user's reserve and confirm. The user had already sent funds to the old miner_from_address, but the validator's verify_transaction call used expected_recipient = new miner_from_address — so the tx looked like it never happened, the confirm was rejected, and vote_initiate was never reached for that reservation. The user's funds were sent, the reservation eventually expired, and the swap terms the validators would have committed to no longer matched what the user agreed to.

Test plan

• ruff check clean on changed files
• Full test suite: 474 passed (was 470 — 4 new cases)
• New TestCommitmentBoundToReserveBlock covers:
  • un-extended reservation reads commitment at reserved_until − 50
  • 2 extensions push the read back by 2 × 250
  • floor-at-1 so a low reserved_until doesn't produce a negative block (substrate would reject it)
  • ContractError on extension-count read falls back to 0 and confirm still proceeds (verified via the queued-confirm path)