security: deterministic advisory scan as an ADDITIVE pre-step

Why: gitea 1.27.1 fixed CVE-2026-60004 + CVE-2026-59774 (both CVSS 9.8). The
2026-08-03 report printed gitea's CVE count as '1', the 2026-08-07 report as
'none'. Cause chain: the upgrade subagent read the GitHub release notes, which
name NEITHER cve (they are announced only in the vendor blog's security section),
so it recorded one unrelated minor item; the report then derived security content
from those notes plus model knowledge, and the model's training predates the CVEs.
Nothing in the pipeline ever queried an advisory source.

cc-ci-plan/advisory-scan.py — deterministic, per recipe, per upgrade window:
  1. GitHub Security Advisories API for every source repo in the upstream registry.
     PRIMARY: CVE + GHSA + severity + vulnerable/patched ranges, so 'fixed by THIS
     upgrade' is computed. Needs no new per-recipe config (134 registry URLs are
     already github.com).
  2. Vendor release/security pages — every registry URL, fetched + regex-scanned.
     This is the source that actually had the gitea CVEs.
  3. OSV where a package mapping exists — supplementary.
Each source reports its own status so 'checked, none found' is never confused with
'not checked'. Source selection was measured, not assumed: for these two CVEs OSV
404'd and NVD's API had them by neither CPE, id, nor keyword — advisory DBs lag the
vendor, hence 1+2 lead.

Wiring is strictly ADDITIVE:
- /recipe-upgrade gains step 2a: run the scan, paste the block into the per-recipe
  log, and report the UNION of it and the existing release-note reading. The scan
  may never lower a count established by reading.
- /recipe-report treats the block as a FURTHER source, prefers its advisory ids /
  severities / fixed-in versions for citation, and must render '?' (not 'none')
  when a scan is absent or has failed sources — the false-clean 'none' is exactly
  what happened on 2026-08-07.
- upstream/gitea.md records blog.gitea.com as the security-announcement URL.

Verified on the real regression: 1.27.0 -> 1.27.1 now yields exactly the 2 missed
criticals with their GHSA ids; the wider 1.26.2 -> 1.27.1 window yields 62.

.claude/skills/recipe-report/SKILL.md

@@ -37,6 +37,15 @@ keeps every weekly edition looking the same regardless of which model writes the
    - **Security analysis.** Scan the per-recipe `upgrade_notes_md` + the summary (and use your own
      knowledge of the version bumps) for upgrades that fix **CVEs / security issues**. For each recipe,
      **count the CVEs** the PR fixes — this drives both the table's `cve` column and the priority sort.
+     - **ADDITIONALLY, and never instead:** each per-recipe log carries an `### Advisory scan
+       (deterministic pre-step)` block (from `cc-ci-plan/advisory-scan.py` — GitHub Security
+       Advisories + vendor security pages + OSV, with severities and fixed-in versions). Treat its
+       CVE list as a **further source** and report the **UNION** of it and what you found by reading.
+       Its entries are machine-derived with advisory IDs, so prefer them for CVE ids / severities /
+       fixed-in versions, and cite the GHSA where present in the Security Bulletin. If a recipe has
+       no scan block, or the block lists **failed sources**, the count is **not** authoritative:
+       render the cve cell as `?` (unknown), never `none` — a blank that reads as "clean" is exactly
+       how two CVSS-9.8 gitea RCEs were reported as "none" on 2026-08-07.
      Anything **critical/high** also gets a `security` bulletin entry (recipe · CVE id(s) + severity ·
      what it fixes · PR link); be specific about severity and what's exposed if not merged.
    - **Lead — ONE short paragraph.** A tight, concrete opener in opus's voice: fleet state in a sentence