advisory-scan: derive windows from a compose diff (--compose-to)

Typing --from/--to/--image by hand means someone has to remember the recipe also
bumped its redis. That is how sidecar CVEs went uncounted for months. Point this
at a PR's compose.yml and it reads the windows off the diff instead.

  advisory-scan.py plausible --compose-to <.../branch/<pr>/compose.yml>
    -> community-edition: v2.0.0 -> v3.2.1
    -> clickhouse-server: 23.4.2.11-alpine -> 24.12-alpine
    -> 6 CVEs, identical to the hand-specified args

Details that mattered:

- keyed by SERVICE, not image repo. plausible moved plausible/analytics ->
  ghcr.io/plausible/community-edition; keyed by repo that reads as one image
  vanishing and an unrelated one appearing, and the app window - the one carrying
  the critical - is lost entirely.
- the baseline is the repo's DEFAULT BRANCH resolved from the API, never assumed
  to be main, because several recipes keep a stale main beside a live master.
- image names are matched against advisory sources BOTH ways: an image name is
  often longer than its source repo (clickhouse/clickhouse-server vs
  ClickHouse/ClickHouse) and sometimes shorter (redis vs redis/redis). One
  direction silently dropped the clickhouse window.
- credentials go in an Authorization header, never the URL: in-URL creds leak
  into shell history and process lists, and urllib mis-parses a password
  containing a colon.

--from/--to/--image remain for finer-grained checks (scanning a window that is
not a literal compose diff). 71 tests; discourse 140 / gitea 2 / mailu 2
unchanged.

cc-ci-plan/advisory-scan.SPEC.md

@@ -39,6 +39,8 @@ keeps landing in pass 2, the fix is a new deterministic method in pass 1. §4c i
 ```
 advisory-scan.py <recipe> [--from <version>] [--to <version>]
                           [--image <name>=<from>:<to>]... [--adjudicate] [--json] [--registry DIR]
+
+advisory-scan.py <recipe> --compose-to <URL> [--compose-from <URL>]   # windows derived, not typed
 ```
 
 | Input | Meaning |
@@ -46,6 +48,8 @@ advisory-scan.py <recipe> [--from <version>] [--to <version>]
 | `<recipe>` | Recipe name; selects `cc-ci-plan/upstream/<recipe>.md` (the per-recipe URL registry) |
 | `--from` / `--to` | The **primary app image's** version window being upgraded across |
 | `--image NAME=FROM:TO` | A **sidecar image and the versions it moved between** (repeatable, all in ONE call). `NAME` is substring-matched against source repo names. Malformed values warn on stderr and are skipped. Without it that image's advisories stay unclassified. |
+| `--compose-to URL` | **Derive every window by diffing this compose against its baseline**, instead of typing `--from/--to/--image`. Point it at a PR's `compose.yml`. |
+| `--compose-from URL` | Baseline for the above. Default: the same repo's **default branch, resolved from the API** — never assumed to be `main`. |
 | `--adjudicate` | Run pass 2: append the evidence dossier for judgement |
 | `--registry` | Registry dir; also `CCCI_UPSTREAM_REGISTRY` |
 | `GITHUB_TOKEN` / `GITHUB_TOKEN_FILE` | Read-only token; **rate limit only** (60/hr anonymous → 5000/hr). Default file `/srv/cc-ci/.github-token`, mode 600. Public advisories need **no scopes**. |
@@ -140,6 +144,33 @@ Two invariants govern this step, both learned from a wrong answer in production.
 > `null` / `UNKNOWN`, never `0`. A `0` in a security column asserts safety. Equally, an advisory that
 > cannot be judged is **indeterminate** (§4d) — never silently counted as "not fixed".
 
+### 3b. Deriving the windows from a compose diff (`--compose-to`)
+
+Typing `--from/--to/--image` by hand means someone has to remember that the recipe also bumped its
+redis. That is how sidecar CVEs went uncounted for months. This mode reads the windows off the diff:
+
+1. Fetch both compose files (baseline = the repo's **default branch from the API**, since several
+   recipes keep a stale `main` beside a live `master`).
+2. Parse `{service: (image-repo, tag)}` — keyed by **service, not image repo**, because an upgrade
+   may change the repo itself (plausible moved `plausible/analytics` →
+   `ghcr.io/plausible/community-edition`; keyed by repo that reads as one image vanishing and an
+   unrelated one appearing, losing the app window entirely).
+3. Every service whose tag or repo changed becomes a window. The `app` service drives `--from/--to`
+   (coop-cloud convention: it is the recipe's primary image); the rest become `--image` windows.
+   Unchanged images produce no window — inventing one would be a false count.
+4. The derived windows are printed to stderr before the scan, so the inputs are auditable.
+
+Image names are matched against advisory sources **both ways** — an image name is often longer than
+its source repo (`clickhouse/clickhouse-server` vs `ClickHouse/ClickHouse`) and sometimes shorter
+(`redis` vs `redis/redis`).
+
+Verified on plausible PR #5: from the compose URL alone it derives `v2.0.0 → v3.2.1` plus
+`clickhouse-server 23.4.2.11-alpine → 24.12-alpine`, and reports **6** — identical to the
+hand-specified args.
+
+`--from/--to/--image` remain available for finer-grained checks (scanning a window that is not a
+literal compose diff, e.g. "what would the compatibility-safe target fix?").
+
 ### 4a. By patched version (preferred — exact)
 
 `patched_versions` is a **range expression** (`">= 2.18.1"`), possibly several joined by `;`. Extract