ci: clean up cargo-deny noise (toolchain probe error + bitflags duplicate)

[StefanSteiner]

Context

Two pieces of cosmetic CI noise observed on the cargo-deny job during the v0.3.0 release pipeline run (example run). Both are informational — the workflow conclusion is success — but they make CI logs harder to scan.

Filing as a v0.3.x cleanup; not blocking any release.

Finding 1 — rustup show stack trace

error: override toolchain 'stable-x86_64-unknown-linux-musl' is not installed
Caused by:
    the toolchain file at '/github/workspace/rust-toolchain.toml' specifies an uninstalled toolchain
Stack backtrace:
   ...

The EmbarkStudios/cargo-deny-action@v2 Docker image ships with 1.85.0-x86_64-unknown-linux-musl pre-installed. When the action runs rustup show, it evaluates rust-toolchain.toml (channel = \"stable\") and tries to honor the override before the toolchain has been installed. The rustup show command exits non-zero with the stack trace, but the action does not propagate that exit code — it then runs rustup install stable (visible immediately after the trace as info: the active toolchain 'stable-x86_64-unknown-linux-musl' has been installed) and the actual cargo-deny check runs cleanly.

The job is green; the trace is just noise. But it looks alarming on first read and adds ~20 lines of stack to every CI run.

Possible fixes

1. Set RUSTUP_TOOLCHAIN: stable env on the deny job in .github/workflows/ci.yml — bypasses the rust-toolchain.toml probe inside the action's container.
2. Pre-install the toolchain before running cargo-deny-action — adds a setup step but produces a clean log.
3. Pin to a specific cargo-deny-action commit that handles this case better, if one exists upstream.

Option 1 is the smallest patch.

Finding 2 — bitflags duplicate version warning

warning[duplicate]: found 2 duplicate entries for crate 'bitflags'
   bitflags 1.3.2 registry+...
   bitflags 2.11.1 registry+...

deny.toml has [bans] multiple-versions = \"warn\", so this is an informational warning, not a failure. Source:

• bitflags 1.3.2 — transitively from core-graphics → core-text (macOS-only, used by plotters for chart rendering)
• bitflags 2.11.1 — modern usage across the rest of the workspace

Cleaning this up requires core-graphics (or plotters's bitmap_backend feature) to bump to a version that depends on bitflags 2.x. Last checked: plotters 0.3.x still pulls core-graphics 0.23.x which pins bitflags 1.3.2. Upstream not yet updated.

Possible fixes

1. Wait for plotters / core-graphics to upgrade to bitflags 2.x. Track upstream; no action here.
2. Add bitflags to [bans] skip = [...] in deny.toml with a comment explaining the macOS plotters chain. Suppresses the warning at the cost of hiding it from future audits.
3. Switch chart rendering to a backend that doesn't pull core-graphics — bigger refactor, probably not worth it for a CI warning.

Option 2 is the smallest patch if we want a clean log; Option 1 is the lowest-effort if we can tolerate the warning.

Acceptance criteria

• cargo-deny step in CI completes without the override toolchain ... is not installed stack trace
• (Optional) bitflags duplicate-version warning either suppressed via skip-list or resolved upstream
• No regression in license / advisory enforcement — cargo-deny check still runs against the full workspace and fails on real policy violations

Priority

Low — cosmetic only. The release pipeline is functional and the v0.3.0 release shipped successfully. Pick this up alongside other v0.3.x housekeeping when convenient.

References

• Workflow run with the trace: https://github.com/tableau/hyper-api-rust/actions/runs/26610521479/job/78415174287
• EmbarkStudios/cargo-deny-action: https://github.com/EmbarkStudios/cargo-deny-action
• Current deny.toml [bans] section: multiple-versions = \"warn\" (intentional — see commit history for rationale)