[Bug]: t3 service install ignores the desktop app's Network access / Tailscale HTTPS settings and binds loopback only #21238

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: t3 update / t3 service install re-render the service unit and drop every user environment variable, including the documented Bitbucket credentials #12626 covers the plist being re-rendered on update; this is about the first install never carrying the exposure settings at all.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

macOS 26.5.2, T3 Code 0.1.0 (desktop via the t3-code cask, CLI via install.sh), main at da7c4f2.

1. In the desktop app enable Network access and Tailscale HTTPS (Settings → Connections). Pair a phone and another Mac; both connect.
2. Quit the desktop app so the environment does not depend on it (the documented reason for the background service).
3. t3 service install.

Expected behavior

The service hosts the same environment with the same reachability the desktop app had, or service install offers --host / --tailscale-serve (the flags t3 serve already has), or at least warns that the exposure settings will not apply.

Actual behavior

The service starts on 127.0.0.1:3773 only. Every paired remote client shows the environment unavailable, with no hint why.

Mechanics:

• The server takes host and Serve only from T3CODE_HOST / T3CODE_TAILSCALE_SERVE or the serve flags (apps/server/src/cli/config.ts L130, L158). It never reads desktop-settings.json, where the app persisted serverExposureMode: "network-accessible" and tailscaleServeEnabled: true.
• renderBootServicePlist (apps/server/src/cloud/bootService.ts ~L152) emits only PATH, T3CODE_HOME and T3_BOOT_SERVICE_UNIT, and t3 service install has no host/serve flags.
• Paired clients survive the switch (the auth_sessions rows are kept), so the data is all there; only the bind is lost.

Workaround

Add T3CODE_HOST and T3CODE_TAILSCALE_SERVE to the plist's EnvironmentVariables by hand and launchctl bootout / bootstrap. Two pitfalls worth a doc line even if the bug stays: the value must be a plist string (-bool true is silently dropped from the environment by launchd), and with Serve on, T3CODE_HOST must include loopback (0.0.0.0), because Serve proxies to 127.0.0.1:3773; a tailnet-IP-only bind answers 502. Both lines are lost again on t3 update (#12626).

Suggested fix

Either of: t3 service install accepts --host and --tailscale-serve and persists them in the unit; or the service reads the desktop exposure settings when it hosts the same T3CODE_HOME; plus a warning at install time when desktop-settings.json requests network exposure that the unit will not provide.