FR: allow users to stay connected across upgrades

[mevanlc]

My original issue text here got hilariously out of date with the progression of this discussion. So I'm deleting it. To see the real deal info, read #127. Meantime, here's some of my revised sales pitch:

---

Each individual benefit might not seem like a lot, but I think it all adds up:

0. Priority number one: make staying connected to late.sh as seamless and easy as possible!
1. Users who, for whatever reason, idle through the 1hour k8s grace period will come back to their computer still connected (well, reconnected) to late.sh!
2. If we do get strong ephemeral state support, upgrade reconnects could possibly happen more automatically than having the user go through pressing q and r. But I still think q, r should seem at least a little friendlier than a full manual reconnect for most people, hopefully.
3. Although I do not address it in this PR, the groundwork for reassociating music automatically is here.
4. If for whatever reason we decide to keep late-cli on direct-ssh path, it can still benefit from some of the reconnect-awareness built here. But to be honest if we build the bastion correctly, I don't see any downside to routing everyone through it.
5. Having late-ssh able to accept connections over WebSocket lays interesting groundwork for spectator mode in a vanilla webbrowser. I am hesitant to let users in for fully-interactive via the web because the barrier to entry is too low and so we get bad eggs. But who can tell the future? I can't.
6. Although I stand by my suggestion to keep bastion as simple as possible (so it doesn't need upgrades), it does provide an interesting location to put BBS-style doorway experiences! It is possible we could have a two-hop bastion system: bastion 1 is super-stable-don't-mess-with-it edition, bastion 2 has room for more complex, possibly less stable doorway experiences. Just a thought, NOT something I recommend, I just point it out as a possibility.
7. Possibility for some application-layer protocol-aware routing or late.sh "Fingerprint IdP" expansion in the future.
8. Bastion on separate hardware = SSH decryption load can be eaten by droplet VMs while late-ssh "big papa" processes get to speak cleartext websocket. Small optimization win maybe, but it's there.

[mpiorowski]

After talking with LLM:

• It will preserve the SSH connection, not the backend session. pty_request currently rebuilds a fresh App from SessionConfig, so reconnect means a full UI/session reset with only DB-backed state reloaded. See late-ssh/src/ssh.rs:547 and late-ssh/src/app/state.rs:382.

• Some state is explicitly in-memory and will be lost on backend restart, especially blackjack. See CONTEXT.md:241.

• The ticket’s terminal reset sequence is incomplete for this app. Current startup/shutdown also toggles mouse tracking, bracketed paste, and OSC 111 background reset. Reconnect logic should reuse late-ssh/src/app/state.rs:643 and late-ssh/src/app/state.rs:659, not just ?1049l.

• After reconnect, the backend must send the equivalent of enter_alt_screen() again. Today that only happens during SSH shell_request: late-ssh/src/ssh.rs:823.

• The doc says maybe fold /tunnel into late-web on :4000, but that’s backwards for this repo. late-web is the web app; late-ssh already owns the axum API on :4000: late-ssh/src/main.rs:204 and late-ssh/src/api.rs:57. Phase 1 should live in late-ssh, ideally on a separate private listener/port.

[mevanlc]

It will preserve the SSH connection, not the backend session.

That's all I want out of it, really. I want to auto-reconnect people to the backend after backend upgrades. Auto-reconnect helps keep the user count high and thus the community bustling = healthy = growth.

Preserving backend state that is already lost today anyway during upgrade is outside the scope of what I wanted out of this item.

But yeah more state preservation across upgrades would be nice for sure. Just not what I intend for this item.

@mpiorowski