Problem:
- remote_ssh.sh detects ssh disconnect by writing a heartbeat every 1s,
which the local side buffers for the whole session.
- The server's stdout (e.g. `io.write()` from a random plugin) writes to
the tunnel, which in theory may contain a bogus "NVIM_READY".
- A nightly install is never updated on the remote.
Solution:
- Supervise the server in `vim.net._ssh.serve()` (Lua). It detects
disconnect via stdin EOF and discards server stdout. The script only
finds or installs `nvim`.
- Also a step toward Windows remotes.
- User may choose "Update Nvim" to reinstall the nightly.
- SshHost fields: follow ssh's "first wins" rule, so e.g. a later User
line in the same block no longer overrides an earlier one.
- Local server now exits on its own when the remote session ends.
- Before auto-install, try existing `nvim` found in remote `$PATH`.
- Combine the remote_ssh_x.sh scripts into one remote_ssh.sh script.
- Ignore `RemoteCommand` from ssh_config, which made ssh refuse our command.
- Don't accumulate the remote heartbeat in memory for the whole session:
`run_wait()` captures output only until it returns.
- Before detaching the UI, check that the remote Nvim answers through the
forward: sshd may refuse the forward, but still run the script.
- Stop the session (tunnel, remote Nvim) if any connect step fails, or if
the UI detached meanwhile.
- Run `ssh -G` once per session, instead of for every ssh command.
- Remote script handles signals at once, instead of after the heartbeat's
- Error if :restart is attempted.
FUTURE: Remote :restart prints a marker, with its [command], on
stdout. It also sends the TUI a restart event pointing at the LOCAL
server. The TUI reattaches there. Local server repeats the remote-ssh
connect steps, and sends the TUI a connect event for the new forwarded
socket. Then it runs [command] (e.g. session restore) on the new
remote over RPC.