Restore first-run welcome before provider setup

[TheGreatAxios]

Summary

Unconfigured first launches were skipping the welcome mountain and going straight into provider/model setup (v0.3.8 regression). This hotfix restores a first-run welcome gate that shows the orange mountain and the line Corbits Code, your local software factory, then continues into provider setup. Users with settings.onboarded still open setup directly.

Changes

• Add src/tui/welcome.ts — standalone welcome surface reusing renderMark / mark grids
• Gate runOnboarding on settings.onboarded; call markOnboarded after continue
• Regression tests for welcome ordering and copy

Test plan

• bun test src/tui/welcome.test.ts src/tui/onboarding.test.ts
• bun run typecheck
• bun run check

Do not merge/release from this PR without an explicit follow-up.

[TheGreatAxios]

Review: hotfix #718 — first-run welcome gate

Reviewed the PR diff against the stated hotfix criteria (fresh gating, onboarded skip, markOnboarded / settings preservation, TUI lifecycle, tests, CHANGELOG claims).

Verdict

No blocking correctness issues — merge-ready once CI is green. (Could not formally Approve: GitHub rejects self-approval on own PR.)

Evidence

Fresh first-run gating (src/tui/onboarding.ts)

• Gate is trueGlobalSettings?.onboarded !== true against globalSettingsPath() (TRUE global), then runWelcome → markOnboarded(trueGlobalPath) → load provider write-target → runProviderSetup.
• Matches desired order: mountain + Corbits Code, your local software factory → provider setup.
• Cancel path returns 1 without stamping or opening setup.

Already-onboarded skip

• onboarded: true on the TRUE global file skips welcome and opens setup directly (covered by onboarding.test.ts).

markOnboarded / settings preservation

• Existing settings are loaded after markOnboarded, so same-path provider merge (mergeProviderIntoSettings / OAuth {...base}) keeps onboarded.
• --config write targets stay independent; onboarded lives only on the TRUE global (same contract as telemetry).
• Reuses existing markOnboarded (disk-fresh, no OAuth token injection). Persistence unit tests still pass.

TUI lifecycle

• welcome.ts mirrors provider-setup teardown: clear interval/timeout → keyInput.off → destroySubtree → renderer.destroy() only when the renderer is owned.
• Settle is idempotent; external harness renderers are not destroyed by runWelcome.
• No resize listener registered (nothing to leak). Sequential welcome→setup renderer create/destroy matches the existing setup→TUI pattern.

Tests

• Local: bun test src/tui/welcome.test.ts src/tui/onboarding.test.ts → 12 pass; onboarded-persistence → 3 pass; bun run typecheck clean.
• Gate ordering, skip, cancel, copy, mark-grid fit, key continue / Ctrl+C / auto-advance are covered and deterministic (injected now / autoAdvanceMs).

CHANGELOG / docs

• Unreleased Fixed note and IMPLEMENTATION.md blurb match the change; do not overclaim restoring every-start Ink animation.

Non-blocking notes (should-fix / file-for-later)

1. Should-fix (coverage): no explicit assertion that an unconfigured --config launch with onboarded: true only on the TRUE global skips welcome (logic is correct by inspection).
2. File-for-later: welcome does not refit the mark on terminal resize; line truncation uses String.slice (ASCII product line today — fine).

Recommended permanent tests (do not implement here)

• --config unconfigured + TRUE-global onboarded: true → call order ["setup"] only.
• Same-path fresh flow already asserts persisted.onboarded === true after provider submit — keep that.