Add corgea advisories check: pre-install package advisory queries for agents

[juangaitanv]

Summary

Adds a read-only corgea advisories check command so agents (and humans) can query the Corgea vuln-api before deciding to install a package or while threat modeling — instead of only learning a package is bad when the corgea npm|pip|... install-wrap gate blocks it.

All lookups go to the vuln-api at https://cve-worker-staging.corgea.workers.dev (the existing DEFAULT_VULN_API_URL), overridable via CORGEA_VULN_API_URL.

Usage

corgea advisories check npm axios@0.21.0   # version verdict — exit 1, per-advisory "fixed in", safe-version steer
corgea advisories check npm axios          # all advisories for the package (pick a safe version before pinning)
corgea advisories check pypi requests --json   # stable schema_version:1 document for agents

Exit codes: 0 clean / not in advisory DB, 1 advisories found, 2 error.

Design

• Versioned form reuses the install gate's /check client — identical verdict semantics and guards on both surfaces; no drift between "check said fine" and "install blocked".
• Unversioned form hits the public /v1/packages/:ecosystem/:name profile route via a new fetch_package_profile (tolerant structs, 404 → "not in advisory database", capped listing flagged as truncated).
• Auth isolation preserved: shared resolve_vuln_api_access — a custom CORGEA_VULN_API_URL never receives the Corgea token unless CORGEA_VULN_API_SEND_TOKEN_TO_CUSTOM_URL=1. Verified by a live header-capture test during validation.
• Shared response handling (shared_status_error, verify_response_identity) deduped between /check and the profile route so the confused-deputy guards can't drift.
• skills/corgea/SKILL.md gains an ### Advisories section instructing agents to check before installing (server-side skill publish is a follow-up; installed agents fetch skill content from the server).

Testing

• 18 new e2e tests (tests/cli_advisories.rs) against the hermetic vuln-api stub: both forms × text/json × exit codes, stdout purity.
• Contract tests (tests/vuln_api_contract.rs, --ignored) round-trip live staging responses through the CLI deserializers.
• Full suite green: 485 tests, ./harness check clean (strict clippy, fmt, skill-drift).
• Live staging smokes: axios@0.21.0 → exit 1 (23 advisories, safe version 0.32.0); unknown package → exit 0; --json emits one valid document.

[cursor]

This 404 handling is too broad. Evidence: fetch_package_profile returns Ok(None) for any HTTP 404 before reading or validating the response body, while /check correctly treats 404 as a route/base-url error. Impact: if CORGEA_VULN_API_URL points at the wrong host/path, an older vuln-api deployment does not have /v1/packages/:eco/:name, or a proxy/CDN returns a generic 404, corgea advisories check npm axios exits 0 and reports “not found in the advisory database (no known advisories)” instead of failing. That is a false clean result for the new pre-install advisory workflow. Concrete fix: only map the route's explicit package-miss response (e.g. parse/compare {"error":"Package not found"} or another stable server sentinel) to Ok(None); treat all other 404 bodies as Err("vuln-api route not found ..."), and add a test for a generic 404/wrong route returning exit 2.