fix: bound txn_counter at the trust boundary (#108)

[Xof]

Closes #108. Stacked on #150.

SECURITY-SWEEP-6

open_existing adopted txn_counter verbatim from the superblock and deserialize read it with no bound, while commit.rs did:

txn_counter.checked_add(1).expect("txn_counter overflowed u64 (2^64 commits) — unreachable")

The comment justifying that expect over a typed error argued overflow is "structurally unreachable". That assumed the counter could only ever be produced by this binary's own increments. It cannot — it is read from a file the threat model says the attacker controls. A superblock forged with txn_counter = u64::MAX, valid magic, an in-range superblock_count and a recomputed XXH3 checksum opens fine, and the first commit after it panics: bypassing the documented poison-and-reopen contract, and surfacing in the PyO3 binding as a PanicException rather than a mapped error class.

The regression test demonstrates precisely this — with the guard removed it panics at commit.rs:133 (the expect itself), not at the assertion.

Why the bound lives in validate()

Not beside the page_size / freemap_depth gates in open_existing, because the counter is per-slot. Selection is "highest counter wins", so a forged slot would win outright. Returning a SuperblockDefect instead makes it lose to a healthy sibling exactly as a bad checksum does — which is what shadow paging is for. Only when every slot is bad does this surface, and then diagnose names the offending field rather than reporting a bare "no valid superblock".

Both behaviours are pinned by tests: all-slots-forged → CorruptSuperblock carrying BadTxnCounter; one-slot-forged → opens from the sibling and still commits.

MAX_TXN_COUNTER reserves 2³² off the top, so the expect now rests on a guarded invariant rather than an argument about counting: a file that opened has 4.3 billion increments of headroom, and a reopen re-validates. The rationale comments at both bump sites (commit.rs, keys.rs) are corrected — they are the sentences a future maintainer would otherwise trust.

Also: CI was not running on any of this

The workflow filtered pull_request: branches: [main], and that filter matches the PR's base. A stacked PR — based on its predecessor so each stays individually reviewable — got no checks at all. The failure was silent: GitHub shows "no checks", which reads as nothing to run rather than never triggered, so the work only met CI after being retargeted to main at merge time, i.e. after review had already happened against an unverified diff. #149 got CI only because it happens to target main directly.

On the other #108 finding

SUPERBLOCK-RECOVERY-4 (sub-page files silently overwritten) already landed on main as #127 — verified against the current tree, no further work needed.

Verification

714 tests pass, clippy and fmt clean. Both new tests verified non-vacuous by removing the guard.