feat: add dependency cooldown

[dewabisma]

Basically adding the dependency cooldown workflow. Enforcing in repo rules will be done later because doesn't have permission.

[n13]

Reviewer model: GPT Sol

Verdict: REQUEST_CHANGES — the pull-request gate works, but the scheduled audit does not respect crates.io's API rate limit.

Blocking finding

• .github/workflows/dependency-cooldown-audit.yml:13: This weekly job delegates a full-lockfile audit to shared-workflows@v1. At the currently resolved tag (32aabd7), audit mode sends one crates.io API request per registry package; this repository has 802 such packages in Cargo.lock. The shared action sets concurrency to one, but its loop starts the next request immediately after the previous request completes, so it does not enforce crates.io's maximum of one API request per second. Sub-second responses therefore turn this audit into hundreds of policy-violating requests and risk the client being throttled or blocked before it can produce a report. Please rate-limit crates.io request starts to at most one per second in shared-workflows (or use the index/database dump for the bulk audit), move v1 to that fix, and rerun this caller.

Validation

• Reviewed the complete two-file diff at c4a38ec2dc1424ce11b514bf86f8ea84aa9a6799 against base 2049564c7793488696eb1e1f82cae3dc5e05ffaf; git diff --check passed.
• The hosted dependency-cooldown / Dependency cooldown job passed and correctly reported Cargo.lock with zero newly introduced versions.
• Inspected the exact reusable-workflow tag and its successful package CI; cargo metadata --locked --offline confirmed 802 crates.io packages in this repository.
• Hosted format, Clippy/docs, and security-audit checks passed. Linux/macOS build-test and examples checks were still running at review time.

[dewabisma]

.github/workflows/dependency-cooldown-audit.yml:13: This weekly job delegates a full-lockfile audit to shared-workflows@v1. At the currently resolved tag (32aabd7), audit mode sends one crates.io API request per registry package; this repository has 802 such packages in Cargo.lock. The shared action sets concurrency to one, but its loop starts the next request immediately after the previous request completes, so it does not enforce crates.io's maximum of one API request per second. Sub-second responses therefore turn this audit into hundreds of policy-violating requests and risk the client being throttled or blocked before it can produce a report. Please rate-limit crates.io request starts to at most one per second in shared-workflows (or use the index/database dump for the bulk audit), move v1 to that fix, and rerun this caller.

I have fixed this in the shared-workflows.

[n13]

Reviewer model: GPT Sol

APPROVE — No blocking findings.

The two caller workflows match the documented shared-workflow contract. The previous crates.io rate-limit blocker is resolved: shared-workflows@v1 now points to merged commit 10f146a, whose audit path reserves one-second crates.io request-start slots, retains one in-flight request, covers the timing behavior with focused tests, and ships the rebuilt action bundle.

Validation:

• Reviewed the complete two-file diff at c4a38ec2dc1424ce11b514bf86f8ea84aa9a6799 against base 2049564c7793488696eb1e1f82cae3dc5e05ffaf; git diff --check passed and both workflow files parsed successfully.
• Ran the current bundled action against this checkout in check mode; it found Cargo.lock, reported zero newly introduced versions, and passed.
• At shared-workflows@10f146a, npm run typecheck, npm run build, and npm test passed (107/107); the committed bundle remained clean after rebuilding. Shared-workflows CI also passed at that commit.
• All seven hosted checks on this PR are complete and successful, including Linux/macOS build-test, Clippy/docs, security audit, examples, format, and the dependency-cooldown gate.

No blocking findings remain.