feat(2): discourse Q4.6 honest upgrade crossover — UPGRADE_BASE_VERSION override (base-on-[-1]) + uniform bitnamilegacy image overlay

Implements the real 0.7.0+3.3.1 -> 0.8.0+3.3.1 upgrade crossover instead of a
§7.1 skip-with-sign-off (Adversary leans DENY on the deferral; agreed):
- recipe_meta UPGRADE_BASE_VERSION=0.7.0+3.3.1 + generic support in
  run_recipe_ci (prev = meta override or previous_version). Harness default
  [-2]=0.6.3+3.1.2 is a hollow base (img 3.1.2 != head 3.3.1); [-1]=0.7.0+3.3.1
  is the PR's true predecessor and shares head's servable 3.3.1 image.
- compose.ccci-health.yml re-pins services.{app,sidekiq}.image to
  bitnamilegacy/discourse:3.3.1 so the 0.7.0 base (compose pins 404 bitnami:3.3.1)
  is servable; idempotent on the head (PR already bitnamilegacy).
Consumes Adversary BUILDER-INBOX (deleted), leaves ADVERSARY-INBOX ack; STATUS-2
discourse section updated. Full lifecycle run launching next.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

runner/run_recipe_ci.py

@@ -724,8 +724,12 @@ def main() -> int:
 
     # Deploy-once base version: previous published version when the upgrade tier will run and one
     # exists (so upgrade goes previous→target in place), else the target (current/$REF). (DECISIONS.)
+    # A recipe may override the base via recipe_meta UPGRADE_BASE_VERSION when the harness default
+    # (recipe_versions[-2]) is NOT the PR's true predecessor — e.g. a PR that adds a version ABOVE the
+    # newest published tag, where the correct base is [-1] (the newest published), not [-2]. The
+    # override must be an exact published version tag (deployed as a pinned base). (Adversary §7.1.)
     want_upgrade = "upgrade" in stages
-    prev = lifecycle.previous_version(recipe) if want_upgrade else None
+    prev = (meta.get("UPGRADE_BASE_VERSION") or lifecycle.previous_version(recipe)) if want_upgrade else None
     base = prev or target
     backup_cap = generic.backup_capable(recipe, meta)
     hook = discovery.install_steps(recipe, repo_local)