fix(auth): structural gate falls through to first-org/first-project when stale IDs miss pendingOrgs

[kelsonpw]

Summary

Fixes the recurring env-picker hang after git reset --hard on a previously-instrumented project. 6 prior PRs (#747 / #760 / #762 / #775 / #778 / #780) each landed a gate that worked at the unit-test level, but the live repro kept reproducing. This pins the actual gap.

Root cause

PR #780 added a structural fallback (needsEnvPickStillRequired → pendingOrgs[0].projects[0]) but only when BOTH selectedOrgId AND selectedProjectId are null. The live restart-after-reset sequence ends up with stale selectedOrgId/ProjectId (not null), so the fallback doesn't fire:

1. resolveCredentials populates pendingOrgs (first fetch) and defers on multi-env.
2. applyEnvSelectionDeferral sets pendingEnvSelection=true.
3. AuthScreen mounts; its single-org/single-project auto-resolve effect writes selectedOrgId='org-1', selectedProjectId='proj-1' from that first snapshot.
4. authTask runs OAuth, fetchAmplitudeUser fetches a SECOND time, setOAuthComplete REPLACES pendingOrgs with the fresh data. If IDs don't match across the two snapshots (re-fetch race, ordering, account changes, stale memory), the existing pendingOrgs.find(o => o.id === selectedOrgId) returns undefined.
5. The structural gate short-circuits to false. If anything then clobbers pendingEnvSelection=false, Auth.isComplete returns true and the router walks past Auth into the Setup-bucket screens. User sees ✓ Auth ─ ● Setup ← with no env picker.

Fix

When stale selectedOrgId/ProjectId don't resolve a project in pendingOrgs, fall through to the same pendingOrgs[0].projects[0] heuristic PR #780 added — instead of bailing to false. The gate is now load-bearing across:

• (a) no IDs picked yet (PR fix(auth): structural gate covers no-pre-selection case (env-picker hang follow-up) #780)
• (b) IDs picked and valid in pendingOrgs (existing happy path)
• (c) IDs picked but stale relative to fresh pendingOrgs (this PR)

Single point of change in src/ui/tui/flows.ts — no new defensive layer.

Regression test

New src/ui/tui/__tests__/env-picker-restart-after-reset-hang.test.ts drives the complete bin.ts startup sequence and asserts the router parks on Auth at every step. The dedicated stale-IDs test failed pre-fix (router resolved to data-setup) and passes post-fix.

A pre-existing test in env-picker-repro.test.ts that asserted the OPPOSITE behavior ("does not block when the resolved project is missing from pendingOrgs") was inverted — it was inadvertently encoding the bug as expected behavior.

Test plan

• pnpm exec vitest run --pool=forks --maxWorkers=1 src/ui/tui/__tests__/env-picker-restart-after-reset-hang.test.ts (new test passes)
• pnpm exec vitest run --pool=forks --maxWorkers=1 src/ui/tui/__tests__/env-picker-repro.test.ts src/ui/tui/__tests__/flow-invariants.test.ts src/ui/tui/__tests__/router.test.ts src/ui/tui/screens/__tests__/AuthScreen.snap.test.tsx (all neighbours pass)
• pnpm tsc --noEmit clean
• pnpm lint clean
• pnpm test — all 4293 tests pass
• src/utils/wizard-abort.ts untouched

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes the wizard router’s Auth completion gating logic; mistakes could trap users on Auth or incorrectly skip the env picker, but the change is small and covered by new regression tests.

Overview
Fixes a regression where the TUI wizard could advance past Auth into Setup screens without rendering the environment picker when pendingEnvSelection was cleared and selectedOrgId/selectedProjectId no longer matched the refreshed pendingOrgs.

needsEnvPickStillRequired now falls back to pendingOrgs[0].projects[0] when the selected IDs are stale (not just null), and tests were updated/added to assert the router consistently parks on Auth across the restart-after-reset sequence and stale-ID scenarios.

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