plan(canon): retire UPGRADE_BASE_VERSION (gated) — plausible's pin becomes redundant under the dynamic canonical base

Operator 2026-06-17: UPGRADE_BASE_VERSION is still used (plausible pins 3.0.1+
v2.0.0 to dodge the broken 3.0.0 base; bluesky-pds references it as a future
re-enable). Once canon establishes plausible's canonical at 3.0.1, the dynamic
base resolves correctly without the pin -> strip the key (meta/resolver/docs/
tests) + migrate plausible + update bluesky-pds note. GATED: keep it if
plausible genuinely still needs the escape-hatch (never drop upgrade coverage).

cc-ci-plan/plan-phase-canon-canonical-sweep.md

@@ -82,6 +82,24 @@ stay pure code: no AI calls during the run. AI (the loops) only authors + verifi
 exact day/time is not critical — pick a low-traffic slot; it's a one-line tune. `Persistent = true` to
 catch up a missed run. This is the only schedule work; do not over-invest in it.
 
+**G. Retire `UPGRADE_BASE_VERSION` if plausible no longer needs it (operator 2026-06-17).** Today it is
+still used: **`plausible`** sets `UPGRADE_BASE_VERSION = "3.0.1+v2.0.0"` (the old static `[-2]` default
+picked `3.0.0`, whose clickhouse entrypoint 404s on amd64 → base never converges; the pin forces the
+newest published `3.0.1`); **`bluesky-pds`** only *references* it (in an `EXPECTED_NA` upgrade-skip note as
+a future re-enable path). Once this phase enrolls plausible and promotes its canonical to its latest green
+release (`3.0.1`), the **dynamic base resolves to `3.0.1` on its own** — the correct base, avoiding the
+broken `3.0.0` — so the explicit pin becomes redundant. Therefore:
+  - With plausible's canonical established at `3.0.1`, **remove the pin from `tests/plausible/recipe_meta.py`
+    and confirm its upgrade tier still resolves the correct base (`3.0.1`) and passes** under the dynamic
+    resolver.
+  - If that holds, **strip `UPGRADE_BASE_VERSION` entirely**: the meta key (`runner/harness/meta.py` KEYS),
+    the override branch in `resolve_upgrade_base` (`run_recipe_ci.py`), the docs (`recipe-customization.md`
+    §4/§5, `testing.md`), and the unit tests (`test_meta.py`, `test_upgrade_base.py`); and update
+    `bluesky-pds`'s comment so its re-enable path is the dynamic base, not the removed key.
+  - **GATE (do not force it):** if plausible genuinely still can't get the right base dynamically (e.g.
+    `3.0.1` itself won't cold-deploy green, so no canonical), **KEEP `UPGRADE_BASE_VERSION`** as the
+    escape-hatch and record why in DECISIONS — never drop a recipe's upgrade coverage to delete a key.
+
 **Plays-nice-with-`samever` (operator wants this CONFIRMED).** The release-tag trigger (D) makes the
 sweep and `samever` **orthogonal** — confirm they don't interfere:
   - In the **sweep**, a recipe runs **only when a new release tag exists**, so the version under test is
@@ -149,6 +167,7 @@ mirror's `main` to upstream, **skips recipes with no new release tag** (even if
 commits), runs CI cold on the new tagged version for the rest, and promotes the canonical only to that
 tagged release — across all enrolled recipes, demonstrated end-to-end in CI, including the run-twice no-op
 determinism proof, the tagged-promote proof, and a real (non-hollow) timer fire. `samever` confirmed
-orthogonal (never fires in the sweep). All recipes enrolled + warm-volume budget recorded; the runtime job
-is AI-free; it is the substitute for the hollow nightly sweep (not a parallel job). M1 + M2 fresh Adversary
-PASSes in REVIEW-canon.md.
+orthogonal (never fires in the sweep). All recipes enrolled + warm-volume budget recorded. `UPGRADE_BASE_VERSION`
+retired (key + resolver branch + docs + tests removed, plausible migrated to the dynamic base) **if**
+plausible works without it — else kept with a recorded reason (§2.G). The runtime job is AI-free; it is the
+substitute for the hollow nightly sweep (not a parallel job). M1 + M2 fresh Adversary PASSes in REVIEW-canon.md.