follow-ups from #1302 review (non-critical)

[anandgupta42]

Anand asked to scope PR #1302 down to just the critical finding (the prompt-history write race, comment 3981939207) plus the two test-isolation fixes (3982134223/3982134283). This issue tracks the remaining, non-critical bot findings from that PR's review so they aren't lost.

Note: fixes for all of these were already written, committed, and pushed to fix/free-default-altimate-base (commit 9af9ab4be9) before this scope change landed. Per instruction they are being left in place as-is (not reverted), but no further work is being done on them under #1302 — this issue is the record for any follow-up review/verification.

• Migration telemetry recorded on a bare quit — 3981939224 (cursor[bot]), 3982012198 (coderabbitai[bot]), 3982134266 (cubic[bot]) — packages/tui/src/component/altimate-onboarding.tsx around line 493-495. onCleanup unconditionally called recordChoice("cancel"); a bare process exit / top-level quit left lastCloseReason undefined, which the old check treated as a genuine decline and emitted altimate_base_choice telemetry that never happened. Fix already in commit 9af9ab4be9: added an explicit chosen flag set only inside no()/yes().

• cycle() doesn't persist the launch default — 3982134204 (cubic[bot]). SUPERSEDED, not just pending re-verification: the original fix here (fallbackModel() preferring a persisted explicitDefault over recent) turned out to introduce a WORSE cross-surface bug — headless/ACP default resolution never read explicitDefault, so the TUI and server could disagree on the launch default after a cycle (see cursor 3986044810/3986264141, cubic 3986055633/3986055646, kilo 3986171198). That branch was reverted and cycle() now reorders recent instead ({ explicit: true, recent: true }), landed directly on PR fix: offer Altimate Base to every user on an implicit free Zen default #1302 in a later commit — done there, not tracked here.

• Startup history merge doesn't enforce dedupe/cap invariants — 3982134235 (cubic[bot]) — packages/tui/src/prompt/history.tsx around line 117. Fix already in commit 9af9ab4be9: added mergeStartupHistory() enforcing no-consecutive-duplicate and MAX_HISTORY_ENTRIES.

• launchDefaultDisplay reads a live memo, not a snapshot — 3982134252 (cubic[bot]) — packages/tui/src/context/local.tsx around line 700. The migration disclosure copy could rename itself mid-dialog once registration moved the live fallbackModel(). Fix already in commit 9af9ab4be9: snapshot launchDefaultDisplay alongside launchDefault at mount.

• Stale "same as Escape/Ctrl+C" comment — 3982134275 (cubic[bot]) — packages/tui/src/ui/dialog.tsx around line 271. Comment predates Ctrl+C's own "interrupt" close reason. Fix already in commit 9af9ab4be9: comments updated to distinguish "dismiss" (Escape/backdrop) from "interrupt" (Ctrl+C).

• migrateLegacyDefault({ from })'s re-check judges explicitness against the live default, not the captured from — 3986171207 (kilo-bot) — packages/tui/src/context/local.tsx around line 834. hasExplicitDefault() compares fallbackModel() (which may have moved by the time yes() re-checks, e.g. after sync.bootstrap() makes a previously-invalid explicitDefault valid again) against modelStore.explicitDefault, instead of comparing against the captured from — the model actually being migrated. Concrete corner case in the finding: a user whose persisted explicitDefault already IS Base can get bounced to the welcome picker instead of accepted. Not yet fixed anywhere.

• persisted() doesn't cover a save() issued before modelStore.ready — 3986171211 (kilo-bot) — packages/tui/src/context/local.tsx around line 802. A save() called while !modelStore.ready only sets a state.pending flag (deferred into the readJson .finally()) and never enters pendingWrites, so persisted() — which awaits only [...pendingWrites] — can resolve before that deferred write has even started. No current caller hits this window (dialog only opens after local.model.ready; the test harness declines post-mount), but the persisted() API's contract is silently violated for it. Not yet fixed anywhere.

• setupComplete() is a global flag, not scoped to "this launch's first-run/impatient-picker case" — 3986532221 (cubic[bot]). This was a genuine regression THIS PR introduced (not a pre-existing follow-up), so it was fixed directly rather than tracked here. Added firstRunOpenedThisLaunch — a one-way latch in altimate-onboarding.tsx set only when the first-run picker actually opens this launch (app.tsx's own fallthrough, or the prompt gate's equivalent, which now also calls markFirstRunActive()) — and app.tsx's shouldSkipOnboardingAtStartup call site now passes setupComplete() && firstRunOpenedThisLaunch() instead of the bare global flag.

• test/context/cycle-stability.test.tsx writes KV lock artifacts to the real global state directory — 3986917361 (cubic[bot]). Fixed directly (repo rule: tests must not touch real global state). Root cause was deeper than the test file itself: kv.tsx's Flock.withLock lock root is derived from Global.Path.state in packages/core/src/global.ts, which had NO test-isolation override at all (only Global.Path.home did), and Flock.setGlobal({ state }) snapshotted that value once at module-import time. Added an OPENCODE_TEST_STATE_HOME override to Global.Path.state (mirroring Global.Path.home's existing pattern) and changed Flock.setGlobal to take a getter over Path.state instead of a frozen value, so it re-resolves on every lock acquisition. The test now sets/restores that env var around its mount. Verified empirically: the real ~/.local/state/altimate-code/locks directory's mtime changed when the fix was temporarily reverted, and stayed untouched with it applied.

• test/context/cycle-stability.test.tsx's three tests are no longer independently runnable — 3987174885 (cubic[bot]). Fixed directly (repo rule: no order-dependent tests). Folded the three sequential test.serial blocks into ONE test() over a single local mount, with five labelled phases (a phase() helper names which stage failed in any assertion-failure message) covering the same scenarios as before.

Follow-up: independently re-verify these fixes (code review + the relevant test suites) outside the pressure of the #1302 merge, since they landed as part of a broader batch rather than being reviewed in isolation. Items 3986171207 and 3986171211 still need an actual fix, not just verification.