Worktree isolation default-on causes confusing stale-deploy bug

The "isolate session in a git worktree" checkbox on the new-session screen defaults to ON in the desktop app. This default is a footgun for any workflow where the user builds/deploys from the main checkout:

1. Claude edits and commits in .claude/worktrees/<name>/
2. Pushes land on origin/main
3. The user's main repo working tree stays at the old commit
4. Builds run from the main repo → produce stale artifacts
5. User uploads stale artifacts → "why is my change not deployed?"

I just spent ~30 minutes debugging exactly this. Symptoms looked like a cache problem (already added a query-string buster), then a build script problem (chased an EXPO_PUBLIC_BUILD_TIME red herring), before Claude finally noticed the deployed bundle hash matched the main repo's stale dist/, not the worktree's fresh one.

Two suggestions:

• Default the checkbox OFF. Opt-in for isolation. The cost of forgetting to opt-in is "I edited in place, fine" — much lower than the cost of forgetting to opt-out.
• Or: when a session is spawned in a worktree, surface a clear banner ("Edits are isolated in .claude/worktrees/foo — your main checkout will need git pull after pushes") so the divergence isn't invisible.