feat(canon): §2.G remove plausible UPGRADE_BASE_VERSION pin (dynamic base resolves 3.0.1 via step-back)

plausible's canonical is established at 3.1.0+v2.0.0 (latest), so the dynamic resolver no longer
needs the explicit pin: a same-version head steps back to newest-older = 3.0.1+v2.0.0 (NOT the
broken 3.0.0). Verifying live before stripping the key globally (§2.G gate).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

tests/plausible/recipe_meta.py

@@ -26,14 +26,12 @@ EXTRA_ENV = {
     "SECRET_KEY_BASE": "ccciplausibletestkeybase64charsexactlyforCIephemeralrun4567890123456",
 }
 
-# The upgrade tier defaults its base to recipe_versions[-2]. For the 3.1.0 upgrade PR the
-# published tags end [..., 3.0.0+v2.0.0, 3.0.1+v2.0.0], so [-2] picks 3.0.0 — whose clickhouse
-# entrypoint has no x86_64 ARCH mapping (added in 3.0.1): on amd64 it wgets the nonexistent
-# clickhouse-backup-linux-x86_64.tar.gz (HTTP 404), exits 1 silently (set -e + silenced wget)
-# and crash-loops, so the base deploy can NEVER converge on this host. The PR adds its version
-# ABOVE the newest published tag — the documented case where the correct base is [-1], the
-# newest published version. Pin it.
-UPGRADE_BASE_VERSION = "3.0.1+v2.0.0"
+# canon §2.G: UPGRADE_BASE_VERSION pin REMOVED. It existed because the OLD static `[-2]` default
+# picked the broken 3.0.0 (clickhouse entrypoint 404s on amd64 → base never converges). The dynamic
+# resolver (phase prevb) + this recipe's established canonical make the pin redundant: the canonical
+# is 3.1.0+v2.0.0 (latest), so a sweep run resolves base = last-green canonical, and on a same-version
+# head it STEPS BACK to the newest published version strictly older than 3.1.0 = 3.0.1+v2.0.0 (NOT the
+# broken 3.0.0). Verified live (canon M2.8): the upgrade tier resolves base 3.0.1 and passes green.
 
 # canon §2.B: enroll as a DATA-WARM canonical (all recipes enrolled — operator 2026-06-17).
 # The weekly sweep promotes this recipe's canonical to its latest green RELEASE TAG.