Pin the schema-version derivation by its invariant

[iceteaSA]

Follow-up to #6, closing the P3 cubic raised there. One test, no production change.

The finding was right; its stated reason was not

cubic's claim was that store_schema_version is only checked to parse as a number > 0, so a regressed derivation is unobserved. That is correct, and I confirmed it by mutation rather than by reading:

.max() -> .min()   ->  22 tests in the area, all GREEN

But the reasoning given was wrong. It said "with the current single-migration list (version 1)"; the list holds 12 migrations, versions 1–12. .min() survives not because there is one migration, but because it returns 1, and 1 > 0 holds. Same verdict, different mechanism — worth separating, because a fix aimed at the stated reason would have been a fix for a condition that does not exist.

Why the obvious fix is the wrong one

The tempting repair is to assert store_schema_version == newest_schema_version(). That restates the derivation against itself: the test would agree with the code by construction and pass whatever the function did. #6 deliberately avoided that, and the manifest-side check can only honestly see shape.

So this asserts the two bounds the result must satisfy, without restating how it is computed:

• no migration in the list exceeds it
• it is a version the list actually contains

Mutation battery

Each with a positive control asserting the target existed exactly once before editing.

mutation	result
.max() → .min()	RED
hardcoded 1	RED
hardcoded 999	RED
.max() → .last()	GREEN

The .last() result is not a gap. While the list is sorted, .last() returns the same value as .max() — an equivalent mutant, a program with identical behaviour, so no test can distinguish it and none should. It becomes a real regression only once the list is unsorted, and the first bound catches it exactly then. Verified rather than asserted, by applying .last() over a reversed view:

FAIL store::tests::newest_schema_version_is_the_highest_migration_this_binary_carries

The comment in the test says this, so the next reader is not left wondering why an obvious mutation survives.

Gate

At the pushed sha f408eb0, network namespace, egress dead by name and raw IP, loopback control live before and after:

578 tests run: 578 passed, 3 skipped
skip census: 15                       (unchanged)
clippy --all-targets: clean
cargo fmt --all --check: clean
Cargo.lock: untouched

Same scope caveat as #6: 4 crates locally, CI runs 6.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Adds a test that pins newest_schema_version() to its invariant, catching regressions the existing manifest-side check misses.

^{Written for commit f408eb0. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}

[synapse-alfonso]

Merged. Verified your mutation claim independently (.max→.min: your test fails naming the reported value; the prior battery stayed green) and the full battery on the merged tree — 387 green. The two-sided bound is the right shape, and the equivalent-mutant note on .last() is the kind of honesty that makes a test trustworthy: it documents what the pin does NOT catch and why that is correct.