ci: build rust-msrv on the MSRV, not the pinned channel

[plusky]

Closes #137.

rust-msrv was not testing the MSRV. The pinned dtolnay/rust-toolchain
action only runs rustup default <tc> — and even that is
continue-on-error — while rust-toolchain.toml outranks the rustup
default, so the job compiled with the pinned channel (1.98.0), not 1.88.
Since rust-msrv is one of main's nine required contexts, an MSRV
violation could land green.

The job now derives the version from Cargo.toml's rust-version,
exports it as RUSTUP_TOOLCHAIN, and asserts the effective rustc before
building — so the literal 1.88 is gone from CI and the old "keep in sync"
comment is replaced by enforcement.

Proof, both directions

Fixed job, replayed step by step:

msrv=1.88
rustc 1.88.0 (6b00bc388 2025-06-23)
Finished `dev` profile ...          REPLAY EXIT=0

Same replay without the export — i.e. main as it stands:

::error::MSRV job is on rustc 1.98.0, expected 1.88     EXIT=1

A deliberate violation (File::lock, stabilised in 1.89) fails the fixed
job and passed the old one:

new wiring: error[E0658]: use of unstable library feature `file_lock`  EXIT=101
old wiring: Finished `dev` profile ...                                 EXIT=0

The workspace genuinely compiles on 1.88 today, --locked included — no
MSRV bump was needed or made.

Why RUSTUP_TOOLCHAIN

cargo +1.88 and rustup override also outrank the toolchain file. The
env var wins on covering every later step, including Swatinem/rust-cache,
whose key is hashed from the effective rustc — with cargo +1.88 the key
would name 1.98.0 while the cached artifacts were 1.88.

Adversarial review before opening

A reviewer re-derived the mechanism, the empty-sed guard, the
version-comparison matrix and the cache-key reasoning independently, found
no vacuous-pass path, and returned NOT MERGE-SAFE on two confidently-false
prose statements: AGENTS.md asserted the toolchain: inputs "all name the
same version" — which this very change falsifies — and three places claimed
RUSTUP_TOOLCHAIN was the only mechanism outranking the toolchain file,
contradicting #137's own list of fixes. Both were verified against rustup
and corrected before this PR.

Related, deliberately not fixed here

rust-beta is inert by the identical mechanism — it installs beta then
compiles the pin, so the early-warning job has been re-testing 1.98.0.
Tracked as #160; switching it on will surface real new-lint noise, which is
a judgement call rather than part of this fix.