Test isolation leak: tui::ui::tests onboarding tests persist a fixture provider into the real ~/.codewhale/setup_state.json

[Hmbown]

Receipt: after two full cargo test -p codewhale-tui --lib runs on this machine tonight (2026-09-06, ~06:44 UTC), the founder's real ~/.codewhale/setup_state.json (mtime matches the run) reads:

"provider_model": { "status": "verified", "result": "provider=fixture-local, model=fixture-model, context_window=128000 (fallback (unverified)) auth=local · not checked, health=attemptable", "version": "0.9.4" }

and codewhale doctor now reports the founder's provider step as verified against a test fixture. fixture-local appears only in crates/tui/src/tui/ui/tests.rs (successful_custom_provider_activation_completes_onboarding, ~line 8105, and its failed_… sibling). The test guards the config path with ConfigPathEnvGuard but not CODEWHALE_HOME, so complete_provider_picker_onboarding_if_switched runs the setup transaction against the real home and Settings::load() reads the real settings.

Two fixes:

1. Targeted: guard CODEWHALE_HOME (temp dir + lock_test_env, the pattern fleet::roster tests already use) in these tests.
2. Systemic: no unit test may touch the real home. Add a test-support guard that fails a test when it resolves codewhale_home() to the developer's real home without an explicit override, or set a per-process temp CODEWHALE_HOME in the test harness entry, so the next leak is a red test instead of a corrupted operator state.

Operator remedy today: rerun /setup provider (or codewhale setup) to re-verify the real provider step.

[Hmbown]

Status: the targeted guard and a hermetic CODEWHALE_HOME for the CI nextest job are on #5933. The process-wide guard is parked here with what it surfaced (branch history in fix/test-home-isolation-5932 before the force-push):

1. A resolver installed in codewhale_paths (install_test_home_resolver, consulted by codewhale_home() after an explicit CODEWHALE_HOME) does stop the leak, but the tui harness keeps two roots: unsealed_test_state_root() is per-holder for env-lock holders and the shared isolated_test_state_root() for everyone else. Routing implicit lookups to either one changes what unguarded readers see.
2. Five legacy-migration and product-dir tests redirect HOME/USERPROFILE and need the real fallback; env_var_currently_guarded("HOME") is the right signal (a captured "real home" is wrong as soon as the first lookup runs under a redirect).
3. tui::provider_picker::tests (135 tests, none holding the env lock) resolve credentials through implicit lookups and, under parallel execution, see each other's fixture config.toml api_key once implicit state is shared — which means today, on main, those tests resolve credential sources against the developer's real ~/.codewhale and pass only because the real config happens not to carry the keys they probe. That is a read-side variant of this issue.
4. test_env_lock.rs is #[path]-included by the integration harness, so the install has to live in test_support (a lock_test_env wrapper), not in the lock module.

Acceptance for the systemic slice: one root policy for implicit and guarded lookups, the picker suite sealed, and the resolver installed from the harness entry points.

[Hmbown]

Also parked: a hermetic CODEWHALE_HOME on the CI nextest job. With an explicit home set for the whole process, four tests fail on every OS — runtime_log::tests::log_directory_prefers_home, runtime_log::tests::log_directory_uses_existing_legacy_deepseek_logs, fleet::executor::tests::executor_runs_real_process_and_drains_stream_json_into_ledger_events, tui::color_compat::tests::backend_writes_render_debug_log_when_enabled — they assert the implicit-home fallback. The systemic slice needs those sealed first.