docs(prevb): update recipe-customization/testing/runbook for dynamic base + previous/ (drop stale recipe_versions[-2] model)

docs/testing.md

@@ -48,8 +48,9 @@ once**; the assertion files (generic and overlay) evaluate the *post-op* state a
 op themselves. Asserted every run: **`deploy-count = 1`** (one `abra app new`).
 
 ```
-deploy ONCE  (base version: the previous published version when an upgrade tier will run and one
-              exists — so upgrade is a real previous→PR-head; else the target / current PR head)
+deploy ONCE  (base version, resolved DYNAMICALLY when the upgrade tier runs: last-green (warm
+              canonical) → target-branch `main` tip → else skip — so upgrade is a real
+              predecessor→PR-head; else the target / current PR head. phase prevb)
   → INSTALL    [optional pre_install seed]   then  generic + overlay assertions   (no op)
   → UPGRADE    [optional pre_upgrade seed]   then  abra app deploy --chaos to PR-head      (op once)
                                              then  generic + overlay assertions
@@ -201,7 +202,11 @@ server's content volume — without it the generic install fails 404, with it it
 
 Concretely, the upgrade tier:
 
-1. base deployment is the **previous published version** (a clean pinned-tag deploy).
+1. base deployment is the **dynamically-resolved predecessor** (phase prevb): last-green (warm
+   canonical, pinned-tag deploy) → else the target-branch `main` tip (chaos deploy of the branch
+   HEAD — the real predecessor the PR merges onto) → else the upgrade tier is skipped. An optional
+   `tests/<recipe>/previous/` supplies version-specific repair to the base ONLY (stripped before the
+   head redeploy). `UPGRADE_BASE_VERSION` may still pin an explicit tag override.
 2. orchestrator captures `head_ref` (preferring `$REF` — the PR head sha; falls back to the recipe
    checkout HEAD for non-PR `!testme`).
 3. on the upgrade tier: re-checkout the recipe to `head_ref` (the prev-tag base deploy reset the