ci(dependabot): hold sha2 at 0.10 until rsa 0.10 ships

[rominf]

Summary

Holds sha2 at 0.10 for major bumps, so Dependabot stops reopening a PR that
cannot be merged.

Root cause. sha2 0.11 is built on digest 0.11. rsa 0.9.10 — the newest
stable release, 0.10 still being at 0.10.0-rc.18 — is built on digest
0.10. The two generic trait sets are not interchangeable, so under sha2 0.11
the SigningKey::<Sha256> and VerifyingKey::<Sha256> uses in
crates/rocm-core/src/lib.rs stop satisfying HashMarker / FixedOutput and
the release-signing path fails to compile. That is #226 in full: six trait
errors, none of them fixable on our side.

The alternative is moving the signing path onto an rsa release candidate, which
isn't a trade worth making for a routine bump. So the major is held and #226
gets closed, with the revisit condition written into the config: when rsa 0.10
ships stable, bump both together and delete the entry.

Scoped to the major deliberately. An unscoped ignore would also suppress
security updates for the dependency. Restricting it to a version-update:
type does not, because those types never match a security-driven update — so
advisories and minor/patch bumps keep flowing.

Risk: low, and it is the reversible kind — deleting three lines restores the
bumps.

Test plan

• prek run --all-files --no-group local-tools passes (check-yaml parses the
  file).

• The incompatibility is not inferred from the version numbers: it is the actual
  compiler output on build(deps): bump sha2 from 0.10.9 to 0.11.0 #226, reproduced against rsa 0.9.10 in Cargo.lock, and
  cargo search rsa confirms 0.10 has no stable release.

• Whether Dependabot honors the entry is only observable after merge; if build(deps): bump sha2 from 0.10.9 to 0.11.0 #226
  reappears, that is the signal it did not take.

• Not a bug fix; no tests/e2e-cucumber/expectations.toml xfail rows to narrow.

[fredespi]

Reviewed at 24b96e4 (one file, +18/-0). No findings — recommendation at the end. I verified the two claims this change rests on rather than taking them from the description, because both are the kind that read plausibly and would be quietly wrong.

The security-update carve-out is correct. This is the load-bearing claim: that scoping the ignore to update-types: version-update:semver-major holds the major without also muting advisories. GitHub's Dependabot options reference confirms it — "update-types only affects version updates, not security updates." So a sha2 advisory still produces a PR, and minor/patch bumps keep flowing. Worth saying explicitly because the unscoped form of this same fix would have silently disabled security updates for a crypto dependency, which is precisely the failure the comment warns against.

The incompatibility story matches the tree. Cargo.lock at this head has rsa 0.9.10, sha2 0.10.9, digest 0.10.7, and crates/rocm-core/src/lib.rs:6455,6476 really do instantiate VerifyingKey::<Sha256> and SigningKey::<Sha256>. So the described break — sha2 0.11 pulling digest 0.11 while rsa 0.9 is bound to digest 0.10 — is consistent with what's actually here, not a guess.

Placement is right. The ignore: key sits at the correct depth inside the cargo entry (sibling to open-pull-requests-limit and groups), and it's the only ignore: in the file, so there's no duplicate-key shadowing.

One thing I checked that could have been a gap, and isn't: I wondered whether the same breakage could arrive by a different route, since the real incompatibility is in digest rather than sha2. It can't — digest doesn't appear in any Cargo.toml here, so it's transitive-only and Dependabot won't raise a version-update PR for it on its own. rsa is pinned at "0.9", and Dependabot doesn't propose pre-releases, so 0.10.0-rc.x won't be offered either. sha2 is the only door, and this closes it.

The comment carrying the revisit condition — bump both together when rsa 0.10 ships stable, then delete the entry — is the right call for a hold like this; it's the part that usually rots.

Recommendation: ready to approve. Trivial diff, correctly scoped, claims verified, CI green (18/18). Note this is currently the only review on the PR, and that it needs an approving review before it can merge — it's BLOCKED on that, not on anything in the change.