ci: CI-style clippy already fails on clippy 1.96 — Linting goes red repo-wide when the runner's stable updates

[aacruzgon]

Summary

cargo clippy --all-targets --all-features -- -D warnings — the CI-style gate — already fails on
a clean checkout with clippy 1.96. CI does not see it yet because dtolnay/rust-toolchain@stable
is still on an older stable. The moment the GitHub runner's stable reaches 1.96, the Linting job
goes red on every branch and every open PR simultaneously.

Reproduced on main-derived branches at clippy 1.96 (ac68faa20c, 2026-05-25):

error: could not compile `helios-auth` (lib) due to 2 previous errors
error: could not compile `helios-auth` (lib test) due to 2 previous errors
error: could not compile `helios-fhir-gen` (build script) due to 3 previous errors
error: could not compile `helios-fhir` (build script) due to 3 previous errors
error: could not compile `helios-hfs` (build script) due to 2 previous errors
error: could not compile `helios-serde-support` (lib) due to 2 previous errors

The 12 lints

Two rules, five files, none of them recently touched:

File	Lines	Rule
crates/auth/src/jwks/fetcher.rs	90, 165	collapsible_if
crates/fhir-gen/build.rs	29, 30, 31	collapsible_if
crates/fhir/build.rs	31, 32, 33	collapsible_if
crates/hfs/build.rs	34, 35	collapsible_if
crates/serde-support/src/lib.rs	161, 162	doc list item without indentation

Clippy 1.96 extended collapsible_if to if let chains, which earlier versions did not flag. The
suggested rewrite is the let-chain form this codebase already uses elsewhere, e.g.:

// crates/auth/src/jwks/fetcher.rs:165
if let Some(val) = directive.strip_prefix("max-age=")
    && let Ok(secs) = val.trim().parse::<u64>()
{
    return Some(Duration::from_secs(secs));
}

That form requires edition 2024 / Rust 1.88+, and the workspace MSRV is already 1.90, so no MSRV
change is needed.

Why this is worth doing before the runner updates

• All 12 are mechanical, and the fix is confined to five files that no open PR modifies — so it can
  land as one small PR with near-zero conflict surface. Waiting means fixing it while every branch
  is red.
• Until then, the CI-style gate cannot pass locally, so a red clippy result is not evidence that
  a given change is at fault. That is a real drag on local pre-flight checks: contributors have to
  hand-verify their own crate with cargo clippy -p <crate> --all-targets --all-features and grep
  the log for the files they touched.

Suggested fix

1. Apply the 12 mechanical rewrites.
2. Consider pinning the toolchain so local and CI agree, rather than tracking stable on both sides
   and drifting again. A rust-toolchain.toml at the workspace root would do it; there is none
   today, and the workflows use dtolnay/rust-toolchain@stable.

Where it came from

Hit while running the required pre-merge checks for #503 (PR #512), whose own files are clean under
--all-features.

[aacruzgon]

CI already allows all of these — this is lower priority than it reads

Verified today on the tip of the #501→#489→#503→#502→#504 stack.

The premise behind this issue is that cargo clippy --all-targets --all-features -- -D warnings exits 101. It does. But that is not the command CI runs. .github/workflows/ci.yml:497 is:

cargo clippy --all-targets --all-features -- -D warnings \
  -A clippy::items_after_test_module -A clippy::large_enum_variant -A clippy::question_mark \
  -A clippy::collapsible_match -A clippy::collapsible_if -A clippy::field_reassign_with_default \
  -A clippy::doc-overindented-list-items -A clippy::doc-lazy-continuation

Every lint in the six offending files sits inside those allowed families:

File	Lint	Allowed by
crates/auth/src/jwks/fetcher.rs:90,165	collapsible_if	-A clippy::collapsible_if
crates/fhir-gen/build.rs, crates/fhir/build.rs, crates/hfs/build.rs	collapsible_if	same
crates/fhir-macro/src/lib.rs	collapsible_if	same
crates/serde-support/src/lib.rs:161-162	doc-lazy-continuation	-A clippy::doc-lazy-continuation

CI's invocation exits 0. So the Linting job is not at risk and never was — there is nothing here that will turn red on its own.

Two things this does change:

1. The caveat several PRs carry is wrong. fix(rest): parse bundle entry URLs without their query string #512, fix(rest): parse bundle entry methods through one shared matcher #515, fix(rest): render batch entry failures through the single-resource error mapping #516 and test(rest): pin the issue codes on #478's two search-entry failure paths #518 all said some version of "the CI-style gate still exits 101 on pre-existing lints tracked in ci: CI-style clippy already fails on clippy 1.96 — Linting goes red repo-wide when the runner's stable updates #513." I've corrected all four. Anyone writing a new PR in this area should run CI's exact line, not the bare form, and will get a clean pass.
2. The real exposure is the allow-list, not the lints. -A clippy::collapsible_if and its seven siblings suppress these repo-wide, including in new code. Local clippy 1.96 extended collapsible_if to if let chains, which is why the local/CI gap appeared; there is no rust-toolchain.toml pin, so CI's stable will reach 1.96 eventually and simply keep allowing them.

Suggest either closing this, or reframing it as "narrow the clippy allow-list" — which is the actual cross-cutting change, and one that should not land inside an unrelated PR since it would conflict with every open branch.