`Test Libs 1.88.0` has never run on 1.88.0: ci.yml:306 hardcodes `stable` (same bug as #2106/#2116)

The test-libs matrix declares toolchain: ["1.88.0", "stable"], but ci.yml:306 installs toolchain: stable literally. matrix.toolchain appears nowhere else in the job except its name, so Test Libs 1.88.0 and Test Libs stable are the same job run twice.

In the latest run on main (33879050611, all 35 jobs green), the Test Libs 1.88.0 job installs stable and reports rustc 1.98.1; the string 1.88 occurs exactly once in its 4101-line log, on the job-name line. test-libs is in the required gate's needs:, so that green is load-bearing.

This is the same defect as #2106 and #2116 ("the ... CI jobs were unintentionally using the stable toolchain from rust-toolchain.toml instead of the matrix-specified toolchain"), both merged a year ago. test-libs is the third matrix-toolchain job in the file and the only one that got neither half — and it needs both, since rust-toolchain.toml pins channel = "stable" and overrides rustup default inside the tree:

      - uses: dtolnay/rust-toolchain@…
        with:
          toolchain: ${{ matrix.toolchain }}          # ci.yml:306, currently `stable`
      …
      - run: cargo xtask test-libs
        env:
          RUSTUP_TOOLCHAIN: ${{ matrix.toolchain }}   # currently absent

That's what check carries at :188/:195 and lint-clippy at :129/:134. Introduced by #1461 (2ef3583e, 2024-11-02): the test job it replaced did pass ${{ matrix.toolchain }} through.

I ran the fix on a fork first, because the useful question is what happens when the leg actually starts running (run 33897565331, four jobs — current wiring and fixed wiring, each over both toolchains):

That failure is not an MSRV break — every real test passes on 1.88.0. The only casualty is ratatui-macros' trybuild case at tests/macros.rs:100, which diffs rustc's stderr for tests/ui/fails.rs against blessed snapshots; those are version-specific, and a channel gate wouldn't help since 1.88.0 is stable. So the two-line fix wants a companion change keeping that one test on a single toolchain. I'd rather flag the constraint than guess at the shape you'd prefer.

Impact, stated plainly: MSRV compilation is still covered, because check's 1.88.0 legs are wired correctly and cargo hack check --all-targets --all-features type-checks tests and benches. What has never happened is MSRV test execution — plus a duplicate job on every CI run.

Filing as an issue rather than a PR because CONTRIBUTING asks that CI configuration changes be discussed first. Happy to send it as a PR, with or without the UI-test gate, if you'd like.

Found by checking which toolchain each matrix leg actually resolves to, using Claude Code (Claude Opus 5). The logs, line numbers and fork runs above are ones I ran and read myself.