test(webconsole): pin the /ui write-action continuation flags in the golden (BACKLOG #1148)

[wshallwshall]

What this is

BACKLOG #1148 dispatched me to build the action-scoped step-up binding on the two admin reset lanes, on both planes. I re-measured first and the entire named deliverable is already shipped at HEAD. So this PR does the two things that were left: it closes the one residual #1148 names that really was unguarded, and it corrects the item's stale opening blockquotes.

This PR does not close #1148 and does not claim to. The item is Verdict: research with Closing-act: scorecard-rescore, which no Builder performs. Its banner is untouched and it stays open.

Re-measurement, by execution at c57903c2c

Anchored on symbols, not line numbers, because the item warns every anchor has moved at least once.

what the item's re-score and filing blockquotes still assert	result at HEAD
admin lane "still rides the shared window", require_step_up on reset-MFA	FALSE. reset_user_mfa and reset_user_password both take require_step_up_action with their own constant
the browser twin rides it too	FALSE. Both console lanes take require_ui_step_up_action
"no admin reset-MFA or reset-password action" (absence claim)	FALSE. Both constants ship in auth/service.py
the combined untagged registry entry	FALSE. Split per-action; revoke-sessions and delete stay combined and untagged on purpose
the gate-ON factory, not the gate-OFF one	TRUE, still

I used the gate-ON factory and changed no route, so the retraction is preserved by construction. I wrote no new dependency: both planes already use require_step_up_action / require_ui_step_up_action, the MFA-gated family. I did not introduce require_reauth_only_action anywhere, and my probes that temporarily swapped it in were reverted -- the diff touches no engine or console source at all. The reason the gate-ON family is right here is the item's own: require_reauth_only_action turns the second-factor gate off, and these routes clear the target's TOTP secret, every recovery code and every passkey in one call. The admin's own enrolment status has nothing to do with the target's.

One positive control moved, and only its number. require_reauth_only_action is now at four route sites, not the two the item pins: the two enrollment lanes plus DELETE /me/sessions/{session_id} and DELETE /me/sessions, added for #1149. All four are self-service, so the 2026-08-22 retraction's argument is untouched and only its count went stale. Recorded in the item so nobody reads a correct count of 4 as the retraction lapsing.

What I built

The golden's step_up / auto_retry / unlock blind spots -- named in #1148 as proposed and unbuilt. _UI_WRITE_ACTIONS is by its own comment the only source of truth for what the step-up re-auth may hand control back to, "the gate that stops the re-auth becoming an open POST/redirect gadget", and those three fields decide it. The golden compared pattern and action only. It now pins pattern<TAB>action<TAB>flags for all 28 registrations, with named flags so a diff says which one moved.

Measured before building, one probe, positive controls in the same runs

step_up=False added to the /ui/users/{id}/reset-mfa registration -- a factor-binding admin lane, and a flip that is behaviourally silent because the branch it disables fires only for a required-but-unenrolled operator.

instrument	result
full console suite	422 passed, 3 skipped, GREEN
engine security-doc drift + rate-limit + security-static + seam-discovery + lint-parity + full API-auth + the golden itself	242 passed, GREEN
the same golden after this column lands	RED, naming the flag that moved

Scope control, so the claim is not wider than the run. The same engine set does catch a gate swap: replacing that lane's require_ui_step_up_action with the MFA-gate-OFF require_ui_reauth_only_action reds test_security_doc_drift::test_every_ui_route_appears_in_the_ui_route_map, which compares the dependency name against a row in docs/SECURITY.md -- public and tracked, so that guard is neither vaulted nor extra-gated. Downgrading to the window-scoped require_ui_step_up reds test_reset_password_shows_temp_once on its bounce assertion. The route's gate was guarded. The registration's flags were not.

Checks

Interpreter named, not assumed: .venv\Scripts\python.exe in this worktree, CPython 3.14.6, cryptography 50.0.1 matching requirements.lock. I never used bare python or the primary checkout's venv.

The [webauthn] extra WAS installed (webauthn 3.0.0), so the two WebAuthn console lanes were live in every run above rather than importorskip-ed. This matters because #1148 records that without the extra a real downgrade runs clean locally.

check	result
ruff check .	passed
ruff format --check .	1256 files already formatted
mypy messagefoundry (strict)	no issues, 268 files
console suite + test_security_doc_drift + test_security_doc_rate_limits + test_api_auth	570 passed, 3 skipped
scripts/docs/backlog_status_check.py	OK, 670 items each declaring one status
pre-commit (all hooks, incl. ledger gate, SPDX, leak guard)	passed

Skipped: the full pytest suite. I ran the console suite in full plus the engine files that can observe this change; the rest of the engine suite is untouched by a console-test-and-golden diff. Legs somebody must read after I exit: the hosted-runner-only ones, including windows-service-smoke, and the SQL Server and Postgres store legs, which skip silently locally.

What I deliberately left

• Shrinking step_up_max_age_seconds, flipping seed_reauth, and binding the roles or channel-scope routes -- each named in the item as visible motion with zero movement on the verb.
• messagefoundry/config/settings.py is untouched. It is the most contended file in flight (reported: items 1117, 1136, 1194 and PRs 842, 879, 883). My change needed nothing there because both action constants already ship in auth/service.py, so I read none of those PRs and there is no hunk to conflict.
• No sibling-owned file is touched: not api/security.py, not routes/core.py, not auth/service.py.
• Still unbuilt and unchanged: the full-factor re-authentication mint, the self-service password lanes, the target-scoped action grant, the console admin user-update edit-unlock work, the client full-factor reauth channel, and the API-Kerberos step-up seeding asymmetry.

Mode

Ultracode: off. No system-reminder in my context said otherwise, which is the whole test.

One probe I could not run: the harness classifier refused the Edit that would have downgraded the second console reset lane's dependency, so the window-gate probe was measured on reset-password only. The reauth_only and step_up probes both ran on reset-mfa.