add /cve-check and /cve-check-and-upgrade

/cve-check answers 'what are we exposed to that an upgrade would fix?' without
running an upgrade: per-recipe, resolve the available window for EVERY image
(sidecars included), run the advisory scan over it, adjudicate whatever pass 1
could not decide, publish a report. Read-only — no PRs, no CI, no merges.

/cve-check-and-upgrade does that sweep, then runs /recipe-upgrade only on the
recipes whose upgrade actually closes a CVE, worst severity first, and reports
on both. --min-severity high for just the urgent ones; --dry-run prints the
queue and stops. Never merges.

Deliberate choices, each written into the skills:
- externals are SWEPT but never upgraded here — a security sweep that skipped
  deployed software would misreport exposure, but we don't maintain them.
- an unknown count never justifies an upgrade AND is never treated as clean;
  it goes to the Addendum.
- no upgrade available means 0 CVEs, not '?'.
- subagents are told which CVEs justify their upgrade, so the PR says why it
  exists — a PR naming the RCE it closes gets reviewed sooner.

recipe-report.py grows a page kind: 'cve' files as cve-DATE.html so a sweep
can't overwrite a weekly edition, while BOTH appear in the same archive index,
suffixed 'full report' / 'CVE check'.

/help and /cc-ci-status updated to route to them.

.opencode/skills/cc-ci-status/SKILL.md

@@ -106,6 +106,12 @@ systemctl --failed --no-legend; df -h / | tail -1; tmux ls
 1. <finding> → /<skill> (or operator action)
 …
 ```
+When a finding is that the fleet's **security exposure is unknown** — the last weekly run failed or
+is stale, so nobody has scanned for CVEs recently — the recommended step is **`/cve-check`** (read-only,
+minutes, no PRs). If it is instead that a known CVE is sitting unpatched, recommend
+**`/cve-check-and-upgrade`** (add `--min-severity high` when only the urgent ones matter). Prefer
+`/cve-check` over waiting for the next weekly run whenever the question is "are we exposed?".
+
 `ALL HEALTHY` requires: recent successful weekly run + published report, no stale tests, no
 CVE PR open >14 days, both hosts <30 days behind their channel, zero failed units, disk under
 thresholds, bridge clean, maintained-set consistent. Anything else is a finding — even minor