test(discourse): UPGRADE_BASE_FLOOR — exclude structurally-invalid upgrade bases

The 0.8.x->1.0.0 discourse recipe family switched app bitnami->official AND db
pgvector/pg17->discourse/postgres:pg18. That db-family change is a structural
break (bitnami cluster lacks the discourse role; pg_upgrade preserves-not-creates
roles) with NO supported in-place path. The dynamic base resolver's step-back
kept selecting 0.8.1+3.5.0 (newest tag below the unbumped 1.0.0+3.5.3 label) and
the upgrade tier red'd twice on this unsupported path (drone #1165, #1171 —
classified stale-test both times; recipe verified green on the real
official->official path).

Adds UPGRADE_BASE_FLOOR (phase basefloor) to resolve_upgrade_base: a recipe_meta
declaration naming the first post-break published version. Resolution stays
fully dynamic (this is NOT the removed sec2.G static pin): the floor only
EXCLUDES below-floor candidates (canonical, step-back, no-canonical fallback);
when no >=floor predecessor exists the tier records a DECLARED skip, never a
silent pass. main-tip fallback unaffected (post-break by construction).

tests/discourse/recipe_meta.py declares UPGRADE_BASE_FLOOR = 1.0.0+3.5.3 with
the full rationale. Unit-verified: head=1.0.0+3.5.3 -> declared skip (was:
0.8.1+3.5.0 wrong pick); post-release head=2026.x -> base 1.0.0+3.5.3 (the real
migration path). No assertion weakened - below-floor in-place upgrades were
never supported coverage.

tests/discourse/recipe_meta.py

@@ -23,11 +23,21 @@ HTTP_TIMEOUT = 1200
 #
 # UPGRADE-tier BASE (phase prevb — DYNAMIC, no hardcoded UPGRADE_BASE_VERSION): the base the head
 # upgrades from is resolved at run time — last-green (warm canonical) → fallback target-branch (`main`)
-# tip → else skip (run_recipe_ci.resolve_upgrade_base). discourse has no warm canonical, so the base is
-# the `main` tip = bitnamilegacy/discourse:3.5.0, which deploys clean (bitnamilegacy exists) with NO
-# `previous/` repair needed. The PR head (recipe-maintainers/discourse#4) switches app to the official
-# `discourse/discourse:3.5.3` and drops the sidekiq service, so the upgrade tier now exercises the REAL
-# bitnamilegacy→official image migration the PR claims to support.
+# tip → else skip (run_recipe_ci.resolve_upgrade_base).
+#
+# UPGRADE_BASE_FLOOR (phase basefloor, 2026-08-04): the 0.8.x→1.0.0 recipe family switched the app
+# bitnamilegacy/discourse → official discourse/discourse AND the db pgvector/pgvector:pg17 →
+# discourse/postgres:pg18. That db-family change is a structural break: the bitnami cluster has no
+# `discourse` role and pg_upgrade preserves-not-creates roles, so an in-place 0.8.x→1.x deploy can
+# NEVER converge (app FATALs `role "discourse" does not exist`, swarm rolls back) — upstream ships
+# no in-place path across it. Without the floor, the resolver's step-back/fallback selected
+# 0.8.1+3.5.0 (newest tag below the head label) and the upgrade tier red'd on this unsupported
+# path twice (drone #1165 2026-07-31 diagnosis, #1171/weekly 2026-08-03 — both classified
+# stale-test, recipe verified green on the real official→official path). Declaring the floor keeps
+# resolution dynamic and only excludes the structurally-impossible bases; when no ≥-floor
+# predecessor exists the tier records a DECLARED skip (never a silent pass). No assertion weakened:
+# below-floor in-place upgrades were never supported coverage.
+UPGRADE_BASE_FLOOR = "1.0.0+3.5.3"
 #
 # compose.ccci.yml is now the ENVIRONMENTAL overlay (all deploys): only app.deploy.update_config.order:
 # stop-first (node memory reality on the upgrade crossover — see its header). The version-specific