ci: make cargo-deny advisory checks non-blocking

[michaeldwan]

Advisory checks run against a live RUSTSEC database that can change at any time. When a new advisory drops (like RUSTSEC-2026-0104 did), it instantly breaks CI on every branch -- main, merge queue, all open PRs -- even though no code changed.

Split cargo deny check into two CI jobs:

• lint-rust-deny (blocking): bans, licenses, sources -- things that only change when we change dependencies
• lint-rust-advisories (informational): advisories only, continue-on-error: true so it shows up as a warning but doesn't gate merges

Added a weekly cron workflow (rust-advisories.yaml) that runs Monday 9am UTC and opens a "security"-labeled issue when new advisories appear, so they don't get lost.

Also added mise run lint:rust:deny:advisories for running advisory checks locally.

This PR should be merged before #2956 (the rustls-webpki bump) -- once advisories are non-blocking, the lockfile update is no longer urgent.

[ask-bonk]

Split cargo-deny into blocking (bans/licenses/sources) and non-blocking (advisories) CI jobs to prevent RUSTSEC database changes from breaking CI on unrelated PRs. The weekly cron workflow will catch new advisories and open issues.

One minor suggestion in .github/workflows/rust-advisories.yaml line 38:

Consider adding a more descriptive fallback message if the grep pattern doesn't match (e.g., if cargo-deny changes its output format):

          SNIPPET=$(grep -A5 'error\[vulnerability\]' /tmp/deny-output.txt 2>/dev/null | head -30 || echo "Advisory details not found in expected format. See CI logs for full output.")

[ask-bonk]

Posted a review comment. The changes look solid - splitting the checks and adding the cron workflow is the right approach for handling the external advisory database.

One minor note: in the cron workflow, the grep extraction of the vulnerability snippet could benefit from a more robust fallback if cargo-deny's output format changes, but this is a low-risk edge case.

github run