feat(kanban): resolve "Staging (human review)", fall back to "FR on staging" (backend#1592 step 1)

[LukasWodka]

Step 1 of the three-step rename in backend#1592. Nothing changes behaviourally — this teaches all five reusables to prefer the new column name and accept the old one, so they work on both sides of the rename instant.

Why a fallback rather than a swap

A rename cannot be done reads-before-writes. Adding a column can — teach everything to read the new name, then start writing it. A rename makes the old name stop existing at a single instant with no period where both are present. Every select(.name=="FR on staging") would resolve to null on the far side of that instant, and null resolution in these workflows means abort or, worse, skip silently.

So each resolver asks for the new name and falls back to the old; each comparator accepts both.

Verified against live board data, in both states

today (only the old name exists): opt_either -> d3caf1d4
after rename (name swapped): opt_either -> d3caf1d4
live id of "FR on staging": d3caf1d4

Same option id either way — which is exactly what the in-place UI rename preserves, and why step 2 must be the UI.

What changed, by kind rather than by file

kind	where
Resolvers (name → option id), new→old fallback	advance-deploy-env, kanban-closure-router, kanban-reconcile (new opt_either helper)
Comparators (status read back from the board), accept both	advance-deploy-env override map + rank(), fr-gaterank(), kanban-reconcile ×3, kanban-closure-router, fr-pass-comment
Write sites, now naming the new column	kanban-closure-router staging branch, advance-deploy-env staging
Existence probe	fr-pass-comment resolves whichever staging-review column exists, keeping its loud failure for the case where neither does

Both rank() functions score the two names identically, so the monotonic never-demote guard cannot read a rename as a backwards move.

fr-pass-comment's probe already carried a comment anticipating exactly this: "this board has been renamed before … so the next rename fails loudly here instead of reporting 'wrong column' for every card." That intent is preserved.

Deliberately not in this PR

18 literal references remain in comments and user-facing message strings. They are correct today and become wrong only after step 2, so changing them now would make the files describe a board that does not exist yet. They are step 3's work.

After this merges — and this order matters

1. Promote to main (callers pin @main, so nothing takes effect until it does).
2. @LukasWodka renames the option in the GitHub UI. Not the API: updateProjectV2Field replaces the whole option set and re-mints every ID — measured 2026-08-05, adding one option preserved 0 of 11 option IDs and blanked 625 of 625 items, recovered only because a name-keyed backup existed (#1576).
3. Dispatch kanban-reconcile with dry-run=true and confirm green.
4. Then step 3 removes the fallback and updates the 18 strings.

Parent backend#1592 → #1552.

---

Note

Medium Risk
Changes sit on promotion gates, deploy advancement, and board writes, but they are additive aliases and fallbacks meant to keep behavior identical across the rename instant; a mistake could still break status resolution or monotonic guards until step 3 cleans up.

Overview
Step 1 of backend#1592 prepares five reusable kanban workflows for renaming the staging functional-review column from FR on staging to Staging (human review) without changing behavior until the board is renamed in the UI.

Resolvers resolve Status option IDs by trying the new name first, then falling back to the old (advance-deploy-env, kanban-closure-router, kanban-reconcile via new opt_either).

Comparators treat both names as the same pipeline stage: rank() in advance-deploy-env and fr-gate, column lists and deploy-state guards in kanban-reconcile and kanban-closure-router, and /fr-pass column checks in fr-pass-comment (including a probe for which staging-review option exists).

Write paths for staging merges now emit Staging (human review); .kanban.yml overrides map both names to the staging deploy environment. Fallback logic is documented as temporary until step 3 removes it.

^{Reviewed by Cursor Bugbot for commit 731481f. Bugbot is set up for automated code reviews on this repo. Configure here.}