Replace cargo audit with cargo deny for CLI dependency policy

[juangaitanv]

Why

cargo audit only checked RustSec advisories. For a binary we ship to customers via npm + pip, that left three supply-chain dimensions untested:

• licenses — a GPL/AGPL crate could ship in the binary
• sources — no lock to crates.io; a git or private-registry dep would pass silently
• bans — duplicate-version bloat, banned crates

cargo deny covers all three plus advisories from the same RustSec DB — a strict superset of cargo audit. One supply-chain tool, no redundant RustSec fetch.

Changes

• deny.toml (new) — version = 2 schema. advisories: deny vuln/unmaintained/unsound/yanked. licenses: permissive allowlist + option-ext's file-level MPL-2.0 (transitive via dirs). bans: warn on duplicate versions / wildcards. sources: lock to crates.io (unknown-registry/unknown-git = deny).
• harness — cmd_audit/_cmd_audit_inner → cmd_deny/_cmd_deny_inner; cmd_ci, dispatch, header, and help updated. Local stays lenient (skips with install hint if cargo-deny absent), CI stays strict.
• .github/workflows/test.yml — install cargo-deny instead of cargo-audit.
• Cargo.toml — mark corgea publish = false.
• AGENTS.md — document ./harness deny.

Note: plan assumption corrected

The plan assumed the root corgea crate had no license and that private = { ignore = true } alone would skip it. In reality:

1. The repo's LICENSE file is GNU LGPL-2.1, which cargo-deny reads as the crate's license (LGPL-2.1-or-later) — so it was rejected, not "no license".
2. private.ignore only skips crates marked publish = false, which corgea was not.

Fix: added publish = false to Cargo.toml. It's factually correct — corgea ships via maturin (npm + pip), never cargo published to crates.io — and it makes private.ignore fire so our own LGPL source is exempt from the dependency-license rules. (This does not weaken the policy for actual dependencies.)

Verification

• cargo deny check → all four checks pass (advisories / licenses / sources / bans; duplicates are warn-only).
• ./harness deny → green ✓.
• ./harness ci → green ✓ (clippy strict, fmt, deny, tests + coverage, 35 passed).
• Negative check: dropping MPL-2.0 from the allowlist → option-ext v0.2.0 rejected, licenses FAILED (exit 4). The policy bites.

Base is chunk1/harness (not main) — that branch is an open PR (#92) and carries the ./harness structure this change modifies, matching the stacked-chunk convention (cf. #93).

[cursor]

Evidence: this comment says the advisory gate fails on yanked crates, but the new [advisories] config only sets version = 2 and does not set yanked. cargo-deny's current default for yanked crates is warn, so cargo deny check will not fail CI when a yanked crate is present. Impact: the replacement policy is weaker than the stated production gate and can ship a yanked dependency while reporting only a warning. Concrete fix: add yanked = "deny" under [advisories] (and keep ignores explicit/reasoned if a yanked crate must be tolerated), or change the stated policy if yanked crates are intentionally non-blocking.

[cursor]

Evidence: lines 11-12 say MPL is being allowed only for option-ext, but putting "MPL-2.0" in the global licenses.allow list permits any current or future dependency with MPL-2.0. Impact: a future dependency/license drift to MPL-2.0 will pass the production license gate without reviewer visibility, which weakens the validation this PR is adding. Concrete fix: remove "MPL-2.0" from the global allowlist and add a crate-scoped exception instead, e.g. exceptions = [{ crate = "option-ext", allow = ["MPL-2.0"] }] under [licenses] (or the equivalent [[licenses.exceptions]] form supported by the chosen cargo-deny version).

[cursor]

Evidence: the harness runs cargo deny check without --locked. Unlike the old cargo audit path, which audited the committed Cargo.lock directly, cargo-deny builds its graph through Cargo metadata and supports a global --locked flag specifically to assert the lockfile will not change. Impact: if Cargo.toml is changed without committing the lockfile update, the dep-policy gate can resolve/scan a transient graph in CI instead of failing fast on the stale committed lockfile, so the reviewed lockfile is not necessarily what the policy validated. Concrete fix: run cargo deny --locked check from the harness (and keep CI using that path) so dependency-policy validation is tied to the committed lockfile.