fix(native): make remote gxserver tunnel survive SSH multiplexing

[gsxdsm]

Problem

Remote machine connections failed at the tunnel stage on every attempt. The debug trail showed ssh -N -L … exiting status 0 with empty stderr within ~0.3s, repeatedly:

attempt localPort=47785 argv=/usr/bin/ssh -N … -L 47785:127.0.0.1:58744 eclipxe@host
code1 tunnel exited early status=0 stderr=<empty>

A manual ssh -N -L 50000:127.0.0.1:58744 eclipxe@host + curl …/api/health/server returned HTTP 200, proving the server, token, protocol, and forwarding were all fine.

Root cause

SSH connection multiplexing. When ~/.ssh/config enables ControlMaster/ControlPath (ssh -O check → "Master running"), an earlier gxserver SSH call (token read) opens a persistent master; the tunnel ssh -N -L then attaches as a slave, hands its forward to the master, and exits 0 immediately — taking its local -L listener down with it. The health probe then can't connect → tunnelFailed, deterministically.

Fix

• Pin the tunnel to a dedicated, non-multiplexed connection (ControlMaster=no, ControlPath=none) so -N stays foreground and owns its -L forward. (the actual blocker)
• Keepalive (ServerAliveInterval=15, ServerAliveCountMax=3, TCPKeepAlive=yes) so an established tunnel isn't silently dropped by idle NAT/firewall timeouts.
• Keychain: write the remote token + saved SSH password to the file/login keychain (kSecUseDataProtectionKeychain=false). Ad-hoc-signed Debug builds have no keychain-access-groups entitlement, so the data-protection keychain rejected SecItemAdd with errSecMissingEntitlement. Also surface the real OSStatus in the keychainFailed toast.
• Diagnostics: richer tunnelFailed detail (ssh stderr / last health HTTP / probe error) and a ~/.ghostex/logs/remote-gxserver-tunnel-debug.log recording the ssh argv and per-attempt outcome.

Testing

• Reproduced the multiplexing exit-0 behavior via the new debug log.
• ./build-ghostex-host.sh succeeds (Debug, arm64).
• Manual tunnel + /api/health/server probe returns 200 through the SSH -L forward.

Notes / follow-ups

• The keychain change unblocks dev builds; for release, a real signing identity with a keychain-access-groups entitlement is still the proper path.
• Scope is intentionally limited to RemoteGxserverClient.swift.

🤖 Generated with Claude Code

---

Update — added commit: resilient/non-fatal token Keychain store. Ad-hoc dev builds get a new signature each rebuild, so a token item written by a prior build stays ACL-bound to it; SecItemDelete can't remove it and SecItemAdd then returns errSecDuplicateItem, which aborted connect with keychainFailed. Now: on duplicate, SecItemUpdate in place; and since the token is read fresh over SSH every connect and never read back from Keychain, any remaining store error is logged (OSStatus) and the connection proceeds instead of failing.