v0.8.67: Launch is slow; profile and remove startup inefficiency

[Hmbown]

Problem

Launch/startup currently feels noticeably slow during local prelaunch testing. This needs a focused v0.8.67 investigation so CodeWhale startup feels immediate enough for repeated TUI use, especially after local rebuild/install cycles.

This report is intentionally symptom-first: do not assume the bottleneck is one subsystem until startup has been measured.

Evidence / context

• Reported from live maintainer QA on June 28, 2026 while testing the local 0.8.66 candidate and Agent-mode approval behavior.
• The user-facing symptom is simply: launch is slow enough to interrupt the test loop and feels inefficient.
• The current startup path may be doing too much eager work before the first interactive frame.

Reproduction / measurement plan

Measure cold and warm startup separately:

1. Fresh shell: time codew --version, time codewhale --version, time codewhale-tui --version.
2. TUI startup to first usable frame in a normal repo with existing ~/.codewhale state.
3. TUI startup with an isolated home/config, e.g. temporary CODEWHALE_HOME, to separate config/session-state cost from binary init cost.
4. Startup inside a large repo versus a small temp repo.
5. Startup with MCP/skills/session restore/project-context paths disabled or mocked, if possible, to isolate expensive eager work.

Capture enough trace evidence to identify where wall time goes before changing behavior.

Likely areas to inspect

• crates/tui/src/main.rs interactive startup and config merge path.
• Config/settings/session loading under ~/.codewhale and legacy .deepseek fallback scans.
• Project context, skills, MCP, model/provider inventory, hotbar/action registry, update check, and sidebar/setup initialization.
• Any network, filesystem scan, release/latest check, or session/history indexing that happens before the first frame.

Expected behavior

• First frame should appear quickly, with slow optional work deferred behind visible status/progress.
• --version should remain fast and avoid full TUI/session initialization.
• Startup should have a small, documented perf budget and a regression test or smoke benchmark where practical.

Acceptance criteria

• Add startup timing instrumentation or a reproducible benchmark/smoke script.
• Identify the dominant startup costs with before/after timings.
• Defer or cache avoidable eager work before first frame.
• Keep behavior correct with existing user settings, large ~/.codewhale state, and large repos.
• Document any intentionally deferred startup work so future releases do not reintroduce the delay.

Related release context

Filed for v0.8.67 follow-up from the v0.8.66 prelaunch/test-build lane. This is not a release artifact and does not imply any tag/publish action.