Desktop-managed SSH hosts never prune old runtimes; each desktop update leaves ~300 MB in ~/.t3/runtime/versions #23108

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. In the desktop app, add a Linux host via Settings → Connections → Add environment → SSH.
2. Update the desktop app (for example nightly to the next nightly) and let it reconnect to the host. Repeat a couple of times.
3. On the host: du -sh ~/.t3/runtime/versions/*

Expected behavior

Runtimes nothing uses any more are removed, as they are for the other install paths:

• t3 update calls prunePinnedRuntimes (keeps current + target).
• scripts/install.sh prunes around its registered launcher.
• The boot service prunes on start (selfUpdate.ts, guarded by launcher.managed).

Actual behavior

Every runtime the SSH launcher ever installed stays on disk. Within about 7 hours of first connecting (the initial install plus two desktop updates), the host had:

300M  ~/.t3/runtime/versions/0.0.46-nightly.20261015.3145
299M  ~/.t3/runtime/versions/0.1.1-nightly.20261020.3438
296M  ~/.t3/runtime/versions/0.1.2-nightly.20261021.3457   # the only one running

No Removed unused t3 runtimes line appeared in any log while the host was SSH-managed. On a nightly desktop this grows by roughly 300 MB per update with no upper bound.

From reading main:

• The SSH launch script generated in packages/ssh/src/tunnel.ts installs into $HOME/.t3/runtime/versions/$T3_ARCHIVE_VERSION. Its only rm -rf calls are for its own lock, its staging directory and the target directory it is about to replace. It never removes other versions.
• The server-side prune in apps/server/src/cloud/selfUpdate.ts only runs if (launcher.managed), which an SSH-launched t3 serve doesn't satisfy.

As a check, I then installed the boot service on the same host (t3 connect --headless, accepting the service). Its first start removed both stale versions:

[21:09:55.446] INFO: Removed unused t3 runtimes.
    versions: [ '0.0.46-nightly.20261015.3145', '0.1.1-nightly.20261020.3438' ]

So prunePinnedRuntimes works on this host. The SSH-managed path just never calls it.

I haven't checked whether pruning belongs in the launch script or in the SSH-launched server's startup. prunePinnedRuntimes already handles the safety cases (running processes, launchers, service references, installs from the last hour), so running it on startup for desktop-managed SSH servers may be the smallest change. I didn't search for macOS hosts behaving differently.

Impact

Minor bug or occasional failure

Version or commit

desktop 0.1.2-nightly.20261021.3486; host runtimes 0.0.46-nightly.20261015.3145, 0.1.1-nightly.20261020.3438, 0.1.2-nightly.20261021.3457

Environment

macOS desktop app (nightly) → Ubuntu 26.04 x86_64 host via Settings → Connections → Add environment → SSH

Logs or stack traces

No response