The j5 command stays on the old version after an in-app update #398

Problem

After the server updates itself from the app, the j5 command on PATH keeps running the previous version.

Seen on the dogfood box on 2026-10-02: the service runs 0.0.47 (runtime/service-state.json activeVersion), while ~/.local/bin/j5 still links to runtime/versions/0.0.44/t3 and j5 --version prints v0.0.44. Agents there call a CLI three versions older than their server.

Cause

~/.local/bin/j5 is a symlink to one specific version directory. Only j5 update repoints it (repointLauncher in apps/server/src/cli/update.ts has a single caller), and it finds the link by looking up its own argv0 on PATH. The other update paths never touch it:

• server self-update through the service launcher (apps/server/src/serviceLauncher.ts), which is what the app's update button uses;
• j5 update run by absolute path, or through a link the lookup doesn't find.

Upstream T3 Code has the same gap with t3 (checked against upstream main, 2026-09-29), so the fix is a give-back candidate for #276.

Done when

• After any update of the server or the desktop app, j5 --version matches the version that is now running, without the person doing anything.
• A rolled-back update leaves j5 on the version that is still running.

Related: #397 (the CLI isn't reachable after install). One mechanism likely fixes both.

Design (agreed with Jackson, 2026-10-03)

Keep upstream's link where it is and add the missing writer:

• When an update commits, the server repoints ~/.local/bin/j5 at its own executable, reusing upstream's repointLauncher. It acts only on a link that already points into this home's runtime/versions, as j5 update does today.
• A rolled-back update restarts the previous version, so the link stays on the version that is running.
• Existing installs need no migration: their link is corrected on their next update (the dogfood box moves off 0.0.44 by itself).
• The server looks for the link at the installer's default location only. A link placed elsewhere with T3CODE_INSTALL_BIN_DIR isn't found and stays as it is; accepted rather than tracked.

Agents don't depend on this link: #397 puts the running server's own directory on their PATH. The fix doesn't touch the service launcher process, and upstream could take it as is.