[Jaro-c]

First step of Glyndor/podup#1552, and the one that has to land before anything else can move.

The problem

A required status check is matched by its name string. Two jobs here build their name by interpolating a value:

line 136:  name: Test (${{ matrix.os }})
line 240:  name: MSRV (${{ inputs.msrv }})

When a consumer changes that value, the job emits a different name, the consumer's ruleset still requires the old one, nothing emits it, and the pull request waits forever — and it is the pull request carrying the change, so the fix cannot be merged from inside it.

MSRV is the worse of the two: not a matrix, but a single job interpolating an input into its own name. The number is informative in the UI and poisonous as a gate name, and it is in the job log either way.

Why not just rename the jobs

Dropping the interpolation would emit MSRV, which no existing ruleset requires — blocking every pull request in every consumer at once. A check-name change is at least as breaking as renaming an input and harder to diagnose: the input is in a file, the name is in a settings page nobody opens.

So this is additive. Two new jobs carry names that cannot move, and consumers migrate their rulesets at their own pace. Test (${{ matrix.os }}) and MSRV (${{ inputs.msrv }}) keep emitting; nothing is removed here.

The one detail that makes them gates rather than decorations

needs: msrv
if: always()

needs: on its own skips the dependent job when its dependency fails, and a skipped required check does not block a merge — the exact failure these jobs exist to prevent. if: always() plus an explicit needs.<job>.result check is what makes them gate. skipped counts as a pass, because both upstream jobs are conditional on caller inputs (inputs.msrv != '', inputs.extra-test-os != '[]'), so a caller that asks for neither has nothing to fail.

The reasoning is in the YAML as comments on purpose. It is what stops someone deleting the if: always() in six months for looking redundant.

Second commit: the generated docs were about to lie

docs/reusables/rust-ci.md tells a consumer which checks are safe to require. Its rule for "conditional" was job.if is not None, so the two new gates — which carry if: always() precisely so they always emit — came out documented as conditional, with always() printed in the "Emitted when" column.

That inverts the table's meaning on exactly the rows a ruleset should be pointed at: it warned readers away from the only two checks in this workflow that cannot become phantoms. The page now reads 6 of 10 conditional instead of 8 of 10. No other reusable page changes — none of them spells out always().

Verification

The gate logic was executed against all four values needs.<job>.result can take, rather than reasoned about:

needs.result	exit	output
success	0	MSRV: success
skipped	0	MSRV: skipped
failure	1	::error::MSRV job did not pass (result: failure)
cancelled	1	::error::MSRV job did not pass (result: cancelled)

actionlint .github/workflows/rust-ci.yml clean. The docs renderer is idempotent — regenerating into a copy and diffing produces no change.

What happens next, and in this order

1. this merges and gets tagged (MINOR — additive)
2. podup bumps its pin, adds an equivalent summary job over its own podman-vm matrix, and lands that
3. only then do podup's two rulesets move to the stable names — new names added before the old ones are removed, or every pull request there blocks
4. later, once no ruleset requires a value-carrying name, this workflow can be simplified

Consumers other than podup will see two new checks appear on their pull requests. They are not required anywhere, so nothing blocks.