Make the stable-toolchain signal visible

The advisory job was marked `continue-on-error`, which GitHub renders as
a green check with an annotation — a signal nobody reads. Removed, so a
failure shows as a real red X.

What now keeps it from blocking merges is branch protection: it has to
stay out of the required status checks. That is a repo setting rather
than anything in this file, so it is called out in ci.yml and CLAUDE.md.
Expect the job red occasionally through no fault of the change under
test; that is the cost of it being visible.

Also runs weekly (Mondays 06:00 UTC). A Rust release lands on its own
schedule, so on push/PR alone breakage could sit unnoticed for weeks.
The pinned `test` and `msrv` jobs skip scheduled runs — a pinned
toolchain against a locked dependency graph cannot change on a timer.

Adds a top-level `permissions: contents: read`, since the workflow needs
nothing more.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -23,12 +23,22 @@ Two versions are pinned, and **three places must agree** when either moves:
 | Dev toolchain | 1.99.1 | `devVersion` in `flake.nix`, `test` job in `ci.yml` |
 | MSRV | 1.88 | `msrvVersion` in `flake.nix`, `rust-version` in `Cargo.toml`, `msrv` job in `ci.yml` |
 
-CI has a third job, `stable`, which tracks latest stable and is marked
-`continue-on-error`. It is **advisory, not a gate**: it exists so a new
+CI has a third job, `stable`, which tracks latest stable and runs weekly
+(Mondays, via `schedule`) as well as on push and PR. It exists so a new
 Rust release that breaks the build or fires a new clippy lint shows up
-before the pin moves, without failing a pull request that did not cause it.
-Check it when bumping `devVersion` — if it is red, the bump needs work
-first. Nothing needs to stay in sync with it.
+before the pin moves. Check it when bumping `devVersion` — if it is red,
+the bump needs work first. Nothing needs to stay in sync with it.
+
+**It is advisory, but it reports red.** There is deliberately no
+`continue-on-error`, because a green check with an annotation is a signal
+nobody reads. That means **it must stay out of the required status checks**
+in branch protection — that repo setting, not anything in `ci.yml`, is what
+keeps it from blocking merges. Expect it red occasionally through no fault
+of the change under test; that is the tradeoff for it being visible.
+
+The pinned `test` and `msrv` jobs skip scheduled runs (`if:
+github.event_name != 'schedule'`), since a pinned toolchain against a
+locked dependency graph cannot change on a timer.
 
 The MSRV is set by the **dependency graph**, not by this crate's code:
 `reqwest` pulls in `url` → `idna` → `idna_adapter` → `icu_*`, and the `icu`