fix: bound txn_counter on the write side too (review follow-up to #151)

[Xof]

Stacked on #151. Together they close #108.

An adversarial review of #151 found that bounding what we accept without bounding what we write is worse than not bounding at all, and reproduced it end to end.

The hole #151 left

MAX_TXN_COUNTER itself is valid — the check is >, not >= — so a file forged at exactly the boundary opens cleanly, with diagnose silent. Neither increment site checked the value it was about to persist, so the commits that follow are acknowledged and fsynced at MAX+1, MAX+2: superblocks this same binary then refuses to read.

Commits past the bound	Outcome
One	The next open silently falls back to an older valid slot, discarding an acknowledged commit
Every slot	The database is permanently unopenable

Both are strictly worse than the forged-u64::MAX panic #151 set out to fix, which at least failed loudly on the first commit rather than a session later.

The engine must never write a superblock it would refuse to read.

The fix

superblock::next_txn_counter is now the single place that decides the next counter; both run_commit and rewrite_crypto_header_inner consult it. run_commit calls it at the top, before any I/O, so a refusal costs nothing and leaves the last durable state byte-identical — which is what the new end-to-end test asserts, by reopening and reading the pre-forge value back.

This also removes the expect entirely rather than merely re-justifying it — the outcome I119 wanted and could not have at the time. There is now a typed fatal TxnCounterExhausted for a condition that is unreachable legitimately and reachable adversarially on the first commit.

Two more from the same review

• The round-trip proptest was a landmine. It still sampled txn_counter in 0u64..u64::MAX while deserialize now rejects the top 2³². A test that fails roughly once in 2³² draws is noise, not signal. Constrained to the validated range — exactly as superblock_count already was, for the reason its own comment gives.
• validate_classifies_each_defect gained a BadTxnCounter case and now pins both sides of the boundary. MAX being accepted is what makes the write-side guard reachable at all, so that assertion is what keeps these two halves honest about each other.

Filed separately

The review found next_handle carrying this defect verbatim — adopted unvalidated at recovery.rs:502, then += 1 unchecked at staging.rs:325, with no bound anywhere. On a plaintext DB a forged u64::MAX panics in debug or wraps to the reserved 0 sentinel in release. Filed as #152 rather than widened into this change.

Verification

716 tests pass, clippy and fmt clean. The new end-to-end test verified non-vacuous by disabling the guard.