Add isolated dev build (make run-app-dev)

[jeremybower]

Closes #635

Summary

Dogfooding an in-development build today means running it against your real ~/.supacode — the dev build and the daily-driver install share the bundle id, data directory, zmx sessions, deeplink routing, Sparkle updater, and CLI socket directory, so the safest workflow is "quit the app you use all day and hope nothing corrupts" (see #635 for the full failure-mode audit).

This adds Supacode Dev, an isolated copy that can run alongside a real install:

• Own bundle id (app.supabit.supacode.dev), name/icon "Supacode Dev", and supacode-dev:// URL scheme — separate UserDefaults domain and LaunchServices/notification/deeplink identity.
• All state under ~/.supacode-dev (settings, sidebar, layouts, worktree clones), so persisted files and restored zmx sessions never collide with prod.
• Sparkle disabled for the dev build, so it can't self-update or be replaced mid-session.
• Socket-dir namespacing: the dev app binds its CLI socket under /tmp/supacode-dev-<uid> instead of sharing /tmp/supacode-<uid>. The bundled CLI (shared binary, no separate product) derives dev-ness at runtime from its own executable path — the bundle id of the enclosing .app — resolves only its own build's socket directory, and cold-launches the app bundle it is embedded in. Each build's supacode always reaches its own app, and running both apps no longer breaks the CLI with "Multiple Supacode instances found".
• Make targets for the loop: make run-app-dev (build + launch), make build-app-dev, make dev (watch, rebuild, relaunch via watchexec), make log-stream-dev.

Implementation notes:

• The dev app is a dedicated Xcode target (supacode-dev) on the standard Debug configuration, produced by the same supacodeAppTarget factory as prod. A custom build configuration breaks the supacode-cli target (Tuist generates external SPM projects with only Debug/Release), and a command-line PRODUCT_NAME override collides the shared frameworks — both were tried. Frameworks, GhosttyKit, and the CLI stay single shared targets, so only the app sources compile twice, and the prod target is byte-for-byte unchanged (Info.plist reads name/icon/scheme via $(VAR:default=…)).
• Dev behaviour is decided at runtime from the .dev bundle id suffix (SupacodePaths.isDevelopmentBuild), not a compile flag, which would force the broken custom configuration.
• The dev app registers supacode-dev:// for OS routing but accepts both schemes, so the CLI's supacode:// payloads work against either build.

Type of change

• Bug fix (the linked issue is a bug report)
• Feature (the linked issue is a feature request marked ready)
• Documentation
• Other (please describe)

How was this tested?

Ran the full local gates on this branch after rebasing onto main, plus new unit tests for the CLI socket-directory resolution (SocketDiscoveryTests: enclosing-bundle detection, dev/prod directory choice, bare-binary and symlinked-CLI fallbacks). Verified manually that the dev app and a prod install run side by side with independent state and that each build's CLI reaches its own app.

• make check passes (format + lint)
• make test passes
• I built and ran the app to confirm the change works

Checklist

• This pull request is linked to an issue with Closes # above.
• For a feature, the linked issue is labeled ready.
• I am the author of this work and accountable for it; no commit is authored or co-authored by an AI agent.
• I have read the Contributing guide and the Code of Conduct.

[sbertix]

I don't know about this one, tbh 😅 do we really need this?

[jeremybower]

Fair question 😄 — the itch this scratches: testing anything that touches persisted state (settings migrations, sidebar buckets, layout snapshots, worktree clone flows) means risking your real ~/.supacode and your actual worktrees. Today the only safe option is back up the dir / use a throwaway machine. The dev build gives you a parallel install with isolated state and no auto-update, so you can break things freely and rm -rf ~/.supacode-dev to reset.

There's also a stability angle: I daily-drive Supacode for agent orchestration, and I've noticed running terminal sessions get flaky when two instances of the same app are open (haven't debugged it yet). Keeping in-flight changes in a separate app means the prod build I actually rely on to do the work stays untouched. make dev (watch + rebuild + relaunch) is the day-to-day payoff — tight edit loop without clobbering the prod app I keep open.

On cost, I tried to keep it cheap and contained:

• Prod target is unchanged — Info.plist just reads $(VAR:default=…), so with no overrides it's byte-for-byte the same Supacode.
• It's one extra Xcode target sharing the same sources; frameworks/GhosttyKit/CLI are built once, so it's not a second full build.
• Dev-vs-prod is a runtime bundle-id check, no compile flags or #if scattered around.

That said, if it's not worth the maintenance surface to you, I'm happy to trim. Options:

1. Keep as-is.
2. Drop the separate icon/scheme polish, keep just isolated ~/.supacode-dev state + make dev.
3. Park it as a doc'd local-only recipe and close the PR.

Whatever you prefer — no attachment here.

[github-actions]

Thanks for the pull request. It doesn't meet the contribution policy yet, so I've labeled it invalid. Please address the following, then push an update:

• Linked issue Isolated dev build for safely testing state-touching changes #635 is not marked ready yet. Bugs are ready on filing; features are marked ready by a maintainer once approved.

Nothing needs to be redone. A pull request left invalid is closed automatically after a few days of inactivity. See CONTRIBUTING.md for the full flow.

[jeremybower]

@sbertix to bring this PR into compliance with the policies, I opened an issue for this feature and added more details on why it is necessary.

[sbertix]

A variation of this, if not exactly this, is definitely coming.
Same as #604, the "stalling" is not about the code implementation but the direction/abstraction itself.

That said, to align expectations further: although I can confidently say this is eventually being merged, please do not expect this to be prioritized any further at this point ("it's not gonna happen today").

[github-actions]

Closing this because it has been labeled invalid and inactive for more than 3 days. Nothing is lost: address the points in the policy comment above and reopen it, and the checks will re-run. See CONTRIBUTING.md.