feat(ci): various ci improvements

[jlizen]

Summary

The CI was missing several checks that are standard in the tower-rs ecosystem. Actions were also referenced by mutable tags, which is a supply-chain risk.

This adds three new CI jobs:

• semver-checks: compares the public API against the last published crate on crates.io using cargo-semver-checks, with --all-features so feature-gated APIs are covered.
• minimal-versions: resolves dependencies to their declared lower bounds and verifies they compile. Catches cases where a bump is needed but the Cargo.toml lower bound wasn't updated.
• test-os: runs the full test suite on macOS and Windows. Relevant because the fs middleware deals with filesystem paths.

All GitHub Actions are now pinned by commit SHA with a version comment (e.g., actions/checkout@de0fac2... # v6.0.2). dtolnay/rust-toolchain is left unpinned since it uses branch refs by design. The taiki-e/install-action@cargo-hack branch ref was converted to the standard @v2 form with tool: cargo-hack input so it can be pinned consistently.

A new .github/dependabot.yml is configured for weekly GitHub Actions updates. Dependabot recognizes the SHA + version comment pattern and will propose PRs with updated SHAs automatically.

Also adds permissions: contents: read and concurrency (cancel-in-progress on PRs) to CI.yml, and a cache step to the check-docs job.

[seanmonstar]

I don't see benefits for pinning actions if all they can ever do is read from the repository, they cannot publish. The downsides are that we don't get fixes, or we have dependabot noise in the repo all the time. It feels like only downsides to me. (I also discussed this in hyperium/http#829, I just link for reference, not to continue the conversation there.)

[jlizen]

That's fair, I'll rip out the pinning.

[jlizen]

CI is red due to semver checks as we have breaking things in-tree (which are already tagged as such in the pending changelog). The workflow intentionally continues on failure.

I think it would probably be more confusing to start staging the version bump ahead of time without the full release PR...

[jplatte]

Re. semver-checks, I think we should compare against the base branch of each PR, rather than the released version.

Also, a comment would probably be nicer than failing CI. Here's two workflows that do that in another project I'm involved in (though in a repo with many crates, so there's some extra complexity there that we wouldn't need here):

• https://github.com/ruma/ruma/blob/aa266b1e15c782322ffcbd2574264ef74ad2ebe6/.github/workflows/semver.yml
• https://github.com/ruma/ruma/blob/aa266b1e15c782322ffcbd2574264ef74ad2ebe6/.github/workflows/semver-comment.yml

I think it had to be split into two steps because some part of it wouldn't work on PRs from forks otherwise.

[jlizen]

Ah, good suggestions @jplatte , appreciate it. I'll update the PR.