fix: declare Rust 1.88 as the MSRV and check it in CI (#377)

[Zheng-Lu]

Summary

Fixes #377, taking option 1 from the issue: raise the declared MSRV to what the locked dependencies need.

The documented MSRV was 1.85, but nothing declared or checked it, and the committed Cargo.lock needs more:

• The default build needs 1.88: idna_adapter 1.2.2 needs 1.86, process-wrap 9 (for rmcp's stdio MCP transport) needs 1.87, and home 0.5.12 and icu_* 2.3 need 1.88.
• The embedded-code-interpreter feature (feat: support code interpreter as gateway execution tool #368) needs 1.98.1: eryx 0.8.0 declares it, and wasmtime and cranelift 48 need 1.95. rust-toolchain.toml is already pinned to 1.98.1 for that feature.

Cargo expects rust-version to cover every feature, so the MSRV is 1.98.1:

• rust-version = "1.98.1" in [workspace.package], inherited by every crate, so older toolchains fail with a clear message. clippy.toml's msrv matches it.
• A new msrv CI job reads rust-version and fails if clippy.toml differs. It prepares the Eryx runtime, because the eryx build script needs it, then runs cargo check --workspace --all-targets --all-features --locked on that toolchain.
• Every workflow toolchain pin is now 1.98.1. Jobs pinned to 1.98.0 had been running 1.98.1 only because rust-toolchain.toml overrode them.
• The container now builds on cargo-chef 0.1.78 with Rust 1.98.1. It had been building with 1.96.0, because the image doesn't copy rust-toolchain.toml, so the new MSRV would have rejected it. cargo-chef publishes Rust 1.98 images only from 0.1.78.
• The clippy suggestions enabled by the new MSRV are applied in a separate commit: if let chains, is_none_or, as_chunks, Duration::from_mins and is_multiple_of. No behavior changes.
• The MSRV is updated in AGENTS.md, the README badge, the getting-started and container docs, and the embedded code interpreter design doc. That doc now says the toolchain pin and the MSRV are both 1.98.1. The provider-aware reasoning design doc no longer says an MSRV repair is pending.
• The observability docs, OtlpProtocol and the unsupported-protocol startup error no longer blame the MSRV for the missing gRPC exporter. The error used to say "gRPC is unavailable below Rust 1.88"; it now says the exporter is not compiled in, matching the zstd compression error.
• The website's copy of the observability page is a release snapshot that refresh-site-docs.mjs regenerates, so it is left for the next refresh.

Test Plan

# With the Eryx runtime prepared (./scripts/setup-eryx-runtime.sh):
cargo +1.98.1 check --workspace --all-targets --all-features --locked   # passes
cargo +1.98.0 check --workspace --locked                                 # refused: "agentic-* requires rustc 1.98.1"
cargo clippy --workspace --all-targets --all-features --locked -- -D warnings   # clean with msrv = "1.98.1"
cargo clippy --workspace --all-targets --locked -- -D warnings                  # clean (default features)
cargo fmt -- --check
cargo test --workspace --locked                                          # 2281 passed, 1 failed, 18 ignored (see below)
uvx pre-commit run --from-ref upstream/main --to-ref HEAD               # includes the file-size ratchet
uvx --with-requirements docs/requirements.txt mkdocs build --strict

• Without the Eryx runtime, the all-features check stops in eryx's build script ("Pre-compiled runtime (runtime.cwasm) not found"). The msrv job prepares the runtime the same way the embedded-code-interpreter job does, and shares its cache key.
• The one test failure is web_fetch::http::tests::the_deadline_bounds_a_slow_origin. It fails the same way on unmodified main under the full suite and passes on its own; this PR doesn't touch web_fetch.
• I dry-ran the job's version-reading step locally: both files read 1.98.1.
• Container: on the old base (cargo-chef 0.1.77, Rust 1.96.0), cargo chef cook is refused with "rustc 1.96.0 is not supported … requires rustc 1.98.1". On the new base, the Rust build stage completes, and both binaries run (agentic-server 0.9.0). My local Docker has no BuildKit, so CI's image build covers the later COPY --chmod step.
• Default features alone would still build on 1.88. On main at 2026-09-30, cargo +1.88.0 check --workspace --all-targets --locked passed, and on today's main every locked dependency outside eryx's tree still declares at most 1.88. The MSRV follows Cargo's expectation that rust-version covers every feature.
• Rebased onto main 8b27941. The clippy autofix commit was redone against current main. ci: reduce duplicate builds and tests #427 removed the provider-upstream job, so that job's toolchain pin is gone too.

Merging alongside #375

#375 (#340) also edits .github/workflows/rust.yml; whichever lands second keeps both changes. Under msrv = "1.98.1", #375 must also pass clippy, which may need the same mechanical autofixes.

[Zheng-Lu]

Rebased onto main 8b27941 and force-pushed (2dce11f).

• The clippy autofix commit is redone against current main at msrv = "1.98.1". It now covers 34 files, all mechanical.
• ci: reduce duplicate builds and tests #427 changed the workflows: I kept its new toolchain components lists with the pins at 1.98.1, and its removal of the provider-upstream job stands.
• main brought two more places that cite the old MSRV, both now updated. The unsupported-protocol startup error said "gRPC is unavailable below Rust 1.88"; it now says the exporter is not compiled in, and its test asserts that. The provider-aware reasoning design doc said an MSRV repair was still needed.
• The website copy of the observability page still has the old wording, because it is a release snapshot regenerated by refresh-site-docs.mjs.

Checks: cargo +1.98.1 check --workspace --all-targets --all-features --locked passes with the Eryx runtime prepared, and cargo +1.98.0 is refused for every workspace crate. Clippy with all features and with defaults, fmt, the size ratchet, pre-commit and mkdocs build --strict pass. Workspace tests: 2,281 passed. The only failure is web_fetch's the_deadline_bounds_a_slow_origin, which fails the same way on unmodified main and passes on its own.

[haoshan98]

Thank you for keeping this up, lgtm.