reconcile-upstream.sh: one deterministic entry point, mandated before PR work

Working against a stale mirror has cost us three different ways:

- mailu #6 was linked as the fix for two internet-facing Roundcube CVEs while
  upstream had already merged AND released it (3.1.3+2024.06.57). The work was
  done; only our mirror was behind. Reconciling closed the PR automatically.
- a stale mirror makes a survey report 'no upgrades available', so the recipe
  silently drops out of the weekly run.
- reading the wrong branch: several coopcloud recipes keep a stale 'main' beside
  the real default 'master'. gitea's main is 1.24.2-rootless while master has
  1.27.1-rootless and the merged PRs, so reading main manufactures a false
  'three releases behind, missing two CVSS-9.8 RCEs' finding.

The reconcile logic already existed inside open-recipe-pr.sh --reconcile-only and
already resolves the default branch itself. What was missing was a single obvious
entry point and a rule saying to run it. reconcile-upstream.sh takes recipes or
--all, and is idempotent — recipe work lives in branches, never on mirror main, so
force-syncing main discards nothing.

/ci-test-review and /cc-ci-tests-update had NO reconcile step at all; both now
require it. /cve-check, /recipe-upgrade and /upgrade-all already reconciled and now
point at the shared script.

.claude/skills/ci-test-review/SKILL.md

@@ -89,6 +89,19 @@ For each real (non-flaky) finding, write the actual fix and open a PR. **Never m
   branch in a SEPARATE clone — **never push `main`, never touch the build loops' working clones**
   (`/cc-ci`, `/cc-ci-adv`) or their in-flight state.
 
+> ### ⚠️ RECONCILE FROM UPSTREAM FIRST — always, before any PR work or upgrade check
+> ```
+> cc-ci-plan/reconcile-upstream.sh <recipe>...   # or --all
+> ```
+> Deterministic, idempotent, and safe (recipe work lives in branches, never on mirror `main`). It
+> force-syncs each mirror to coopcloud's **default branch — resolved from the API, `main` OR
+> `master`** — and closes any mirror PR whose changes upstream already merged. Skipping it has cost
+> us three distinct ways: mailu #6 was reported as the fix for two internet-facing CVEs while
+> upstream had already merged AND released it; a stale mirror makes a survey report "no upgrades
+> available" so the recipe drops out of the weekly run; and reading the wrong branch on a recipe with
+> a stale `main` beside a live `master` (gitea) manufactures a false "three releases behind, missing
+> two CVSS-9.8 RCEs" finding.
+
 ### 5. VERIFY each PR on the CI server (deterministic; still never merge)
 A PR is only "working" once **cc-ci verifies it green** (operator rule) — dogfood the CI that found
 the bug. Verification is deterministic (the harness), not an AI judgement.

.claude/skills/cve-check/SKILL.md

@@ -57,7 +57,8 @@ This is `/recipe-upgrade` step 1's research, stopping before it implements anyth
 >    vectorchord/pgvectors versions immich-server is built against, so taking the newest would break
 >    the deploy. `all_resolved: false` means an image could NOT be resolved — that is a `?`, never a 0.
 
-**Reconcile the mirror from true upstream FIRST — ALWAYS, no exceptions.** This is the same reconcile
+**Reconcile the mirror from true upstream FIRST — ALWAYS, no exceptions** — one command,
+`cc-ci-plan/reconcile-upstream.sh <recipe>... | --all`. This is the same reconcile
 `/upgrade-all` does. Do not skip it in the name of keeping the sweep read-only: skipping it makes you
 research a stale checkout, and on the first real run that produced **two recipes with no survey output
 at all**, which is indistinguishable from "no upgrades" unless you check. It is safe — recipe work