fix(1301): move ref access out of render in staff user edit route

[radandevist]

Closes #1301

Summary

apps/front/src/routes/authed/staff/staff-users/$userId-edit.tsx emitted oxlint react(refs) during-render warnings. This PR removes every during-render ref access with zero behaviour change:

• knownProfileNamesRef (read during render) → knownProfileNamesById state, seeded lazily on first render and absorbed through React's documented adjust-state-during-render pattern with content-key guards, so the store converges without effects or refs.
• hasLoadedProfilesRef (read during render in the profiles-loading early return) → hasLoadedProfiles state.
• hydratedUserIdRef is kept unchanged: it is only accessed inside an effect, which is allowed.

Components remain function declarations; no class methods involved.

Round-1 review fixes (this update)

Round-1 verdict: APPROVED_WITH_FOLLOW_UPS, one MAJOR blocking finding plus one NOTE. Both are fixed here:

MAJOR — nav guard read render-frozen state across the save→redirect seam

shouldBlockFn: () => formState.isDirty && !hasSaved decided from React render snapshots. TanStack Router's history.block stacks every registered closure and consults them ALL at navigation time, so a closure registered on an earlier render kept answering with stale data exactly during the post-save redirect: a successful save could still show "Leave without saving?" (flushSync cannot help either — older stacked closures stay frozen regardless).

Fix: the guard now decides from values readable LIVE at navigation time. Two module-level maps keyed by userId hold the pristine hydration snapshot and the last successfully saved snapshot:

• written ONLY outside render (hydration effect / submit success path, synchronously BEFORE navigate());
• read ONLY inside the guard callback (invoked during navigation, outside render);
• staffUserEditValuesMatch() does strict per-field equality against the saved-or-pristine baseline;
• a fresh re-hydration deletes the stale saved snapshot, so a revisit compares against current server truth, not a previous visit's payload.

NOTE — catalogueSeenKey could throw during render

The seen-payload key was JSON.stringify([isSuccess, profilesQuery.data?.data ?? null]). Serialising the raw query payload throws DURING RENDER if a catalogue row ever carries a cyclic value. It now derives from stable row identities (id + name), the same content the assigned-side key already uses — same loop-safety guarantee, no throw path.

Regression test — real router, not a mocked blocker

New apps/front/src/routes/authed/staff/staff-users/$userId-edit.blocker.test.tsx mounts the REAL $userId-edit route object (same module identity, .update()-mounted like routeTree.gen does) onto a throwaway tree with a real createRouter + createMemoryHistory, so useBlocker registers into the genuine stacked-blockers pipeline. Only network-facing hooks/toasts/i18n are faked. Two tests:

1. the reviewed MAJOR: dirty BOTH identity and profile assignments → Save → mutations resolve → redirect must LAND on the detail route with no "Leave without saving?" dialog.
2. overcorrection guard: a genuinely dirty Cancel navigation is still blocked with the confirm dialog.

Paired red/green proof

Original ref-removal proof (excerpts from .dump/red-green-proof.md, gitignored directory):

• Step 1 — characterization GREEN on the pre-fix (ref-based) implementation: targeted suite $userId-edit.test.tsx = 29 passed (27 pre-existing + 2 new tests pinning the ref-driven behaviours: off-page label memory after deselection; no loading flash once profiles have loaded).
• Step 2 — RED: with react/refs enabled as error for the file, oxlint '$userId-edit.tsx' exits 1 with 5 react(refs) findings.
• Step 3/4 — GREEN: after the fix the same oxlint invocation exits 0 with zero findings, and the targeted suite passes 29/29.

Round-1 blocker red-proof (captured in .dump/red-blocker.txt, gitignored directory):

• RED — with the round-1 fix reverted (stash of $userId-edit.tsx only), the real-router MAJOR test FAILS exactly as reviewed: the redirect never lands, the page stays behind the unsaved-changes confirm dialog until timeout; the companion still-blocks test keeps passing on both versions (the old code blocked correctly for the non-save case — proving the failure is specific to the save→redirect seam, not a harness artefact).
• GREEN — with the fix restored, both tests pass; full targeted suites: 31/31.

Rule enforcement

react/refs is enabled as error for this exact file through a scoped .oxlintrc.json overrides entry. No rule loosening anywhere: every other rule in the shared config is untouched, and no inline disable directive was added.

Commits:

1. 4a0ab35c7 — test(1301): pin ref-driven profile-label memory and no-reload behaviours
2. e63d5df08 — fix(1301): move ref access out of render in staff user edit route
3. 78e1f88f7 — fix(1301): decide nav guard from live values across save->redirect (round-1 review fixes)

Gates run locally

• Targeted suites: $userId-edit.test.tsx + $userId-edit.blocker.test.tsx = 31/31 (re-run on the rebased tip)
• Full front unit/component suite (pnpm --filter front test) — exit 0 on the rebased tip
• pnpm --filter front typecheck — clean
• pnpm lint (oxlint quiet repo-wide + disables guard + barrels guard) — exit 0; npx oxlint '$userId-edit.tsx' exits 0 with the scoped override active
• pnpm format (oxfmt --check) — exit 0
• just ci-drift — exit 0
• API integration specs intentionally not run: frontend-only change, no API surface touched

Rebase after #1305

Rebased onto origin/develop at a33ed361a (rebase chosen over merge: linear, small history). Conflicts touched exactly two files:

• apps/front/src/routes/authed/staff/staff-users/$userId-edit.tsx — one hunk, the pending gate. Resolution keeps BOTH intents: develop's QueryDisplay PR 2 hoisting of query flags into plain locals (detailsIsPending / assignedProfilesIsPending / profilesIsPending) AND this PR's replacement of the during-render hasLoadedProfilesRef.current read with the hasLoadedProfiles state.
• .oxlintrc.json — auto-merged cleanly (additive-merge file); this PR's scoped react/refs: "error" override for the exact route file is intact, nothing else in the shared config changed.

Post-rebase conformance with develop's new publy/prefer-query-display enforcement (#1305): the round-1 NOTE fix's catalogue seen-key read profilesQuery.isSuccess directly inside a conditional, which the new rule flags. Re-expressed with develop's own hoisted-local idiom from the same file (const profilesIsSuccess = profilesQuery.isSuccess): identical values and behaviour, no disable directive, no rule loosening. npx oxlint on the route file is clean with the scoped override active.

The resulting route file was re-read top to bottom: hooks single and ordered, one ladder only, no duplicate hooks, no leftover ladder, no ref read in render (hydratedUserIdRef remains effect-only).

Gates on the rebased tip: targeted suites 31/31 — including the r1 regression (both-dirty save → redirect lands with no "Leave without saving?") and both ref-behaviour pins — plus the full front suite, typecheck, pnpm lint, pnpm format, and just ci-drift; all green.

Model line: Ox Alpha (stealth/ox-alpha via Nous Portal, max, jcode).

Unverified

• Per the lane verification policy (captain, 2026-08-23 15:30), the local e2e stacks (just ci-e2e-front, docker compose test stack) were NOT run. CI runs front-e2e on the PR and that is the evidence for end-to-end behaviour.
• StrictMode double-render behaviour is asserted indirectly through jsdom tests, not a real browser StrictMode run.

Model line: Ox Alpha (stealth/ox-alpha via Nous Portal, max, jcode).

[radandevist]

Adversarial review r1 (tencent/hy3:free via Nous, high): APPROVED_WITH_FOLLOW_UPS, but the MAJOR is a user-facing regression — after a successful both-dirty save, the nav blocker can read a stale hasSaved=false (async setState replaced a synchronous ref write) and show "Leave without saving?". The captain treats it as blocking. Fix lane dispatched: synchronous saved-state for the blocker + real-router regression test with paired proof. Verdict in .dump/verdict-r1.md.