Feature request: keep the initial binary as the server (pin / no-auto-upgrade)

Feature request: keep the initial binary as the server (pin / no-auto-upgrade)

Problem

Currently jcode uses a shared server daemon (~/.jcode/builds/shared-server/jcode) that can get upgraded independently of the binary you launched. When testing regressions across versions, you must jump through hoops: isolated sockets, --no-update, and manual symlink management.

Proposed solution

A way to tell jcode: "the binary I just launched IS the server — don't swap it, don't upgrade it, keep using this exact binary."

For example:

• jcode --pin or jcode pin — the launched binary acts as its own server; no shared-server symlink involvement
• JCODE_PIN=1 — environment variable equivalent
• Works naturally with versioned launchers (jcode800, jcode801) — each stays on its own binary

Behavior

• The initial binary is the server for the lifetime of that session
• No symlink to a shared daemon; no background upgrade
• A pinned session gets its own isolated socket (e.g., based on binary version + hash or a user-specified name), preventing protocol mismatches with other sessions
• jcode --version and /version reflect the actual running binary

Use cases

1. Regression A/B testing: jcode800 in one terminal, jcode801 in another, each with its own binary and socket — no cross-contamination
2. Stability: pin a known-good version until a bug is fixed upstream
3. CI/CD: pin a specific version for reproducible agent workflows

Related

• #323 — server version mismatch workaround (made obsolete by this)
• #349 — /version command

Start by tracing the shared-server launch, upgrade, symlink, socket, and version-handling paths described in the issue. The feature is done when a pinned session keeps the launched binary for its lifetime, avoids shared-server upgrades and symlinks, uses an isolated socket, and reports that binary's version.