terminal: stop replaying questions, stop opening two sockets, bind the word keys

three separate faults behind "reconnecting gets weird and the keyboard is not
natural".

── the replay typed into the shell ──

the pty buffer was stored raw and replayed verbatim on every re-attach. anything
in it that ASKS the terminal a question — DSR, DA, DECRQM, XTVERSION, XTGETTCAP,
the OSC colour queries — got asked again, and xterm answered correctly by writing
the reply to its input. the pty receives that as a keystroke nobody typed.

stripped on the way IN, since the buffer is the thing that gets replayed and a
live client already answered them once when they were legitimately asked. only
questions are removed; everything that draws is untouched. where a control shares
its final byte with one that draws, the parameter is enumerated rather than
wildcarded — CSI 18 t asks the window size, CSI 22 t pushes the title, and
stripping the second would change what a replay renders. 36 tests, both
directions, because both fail silently.

── two sockets on one session ──

handleClose armed a reconnect timer; handleVisibilityChange fired on tab focus
whenever readyState was CLOSED — which is exactly what a pending timer leaves.
both ran. every keystroke went twice, two replay frames fought over the screen,
and only one socket was ever cleaned up because __terminalCleanup is overwritten
by whichever connect ran last. connect() is now the single guard, and a stale
socket's close no longer speaks for the session.

── the keyboard ──

alt-arrow was dead for everyone: xterm.js 5 rewrote it into the ctrl-arrow
sequence, xterm.js 6 removed that rewrite and emits the honest ^[[1;3C/D
(verified — the string 1;3D does not appear anywhere in the 6.0 bundle). nothing
bound it. so it broke on a dependency bump, with no shell config changed.

bound in zsh rather than translated in the browser, deliberately: tmux.conf
claims M-Left/M-Right for pane switching, and a client-side rewrite would send
^[b to tmux and break it. the real sequence lets tmux handle it inside a session
and zsh outside.

ctrl-arrow was worse and more embarrassing: it worked for MEMBERS and not for the
OWNER. shell-skel/zshrc has had the bindings all along; the owner's .zshrc is
assembled in machine-setup and never got them. the owner had a strictly worse
shell than the accounts they provision. confirmed with `zsh -i -c bindkey`
before and after.

also: escape-time 10 in tmux.conf. the 500ms default delays every Alt chord and
every Escape, which is most of what "not natural" felt like.

applied to this host by hand — setup only runs at install. cmd+arrow is left
alone: xterm emits nothing for it, so there is no sequence to bind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/shell-skel/zshrc

@@ -58,9 +58,30 @@ bindkey '^[[A' up-line-or-beginning-search    # Up: history matching what is alr
 bindkey '^[[B' down-line-or-beginning-search
 bindkey '^[[1;5C' forward-word                # ctrl-arrow by word
 bindkey '^[[1;5D' backward-word
+bindkey '^[[1;3C' forward-word                # alt-arrow by word — see below
+bindkey '^[[1;3D' backward-word
 bindkey '^[[3~' delete-char
 bindkey '^[[H' beginning-of-line
 bindkey '^[[F' end-of-line
+bindkey '^[[1~' beginning-of-line             # the other Home/End encoding; terminals disagree
+bindkey '^[[4~' end-of-line
+bindkey '^H' backward-kill-word               # ctrl-backspace (and alt-backspace, which sends ^[^?)
+bindkey '^[^?' backward-kill-word
+bindkey '^[[3;5~' kill-word                   # ctrl-delete
+
+# Why alt-arrow needs binding at all, given ^[b/^[f already work.
+#
+# xterm.js 5 rewrote Alt+Left/Right into the ctrl-arrow sequence, so `^[[1;5D` covered both. **xterm.js 6
+# removed that rewrite** (verified: the string `1;3D` does not appear anywhere in the 6.0 bundle), and now
+# emits the honest `^[[1;3D`. Nothing bound it, so alt-arrow became a no-op the moment the dependency moved
+# — on a machine where nobody had changed a line of shell config.
+#
+# Bound here rather than translated in the browser on purpose: `tmux.conf` claims M-Left/M-Right for pane
+# switching, and a client-side rewrite would send `^[b` to tmux and break that. Letting the real sequence
+# through means tmux gets it inside a session and zsh gets it outside, which is what both expect.
+#
+# Cmd+Left/Right is deliberately absent: xterm emits NOTHING for it (`case 37: if (e.metaKey) break`), so
+# there is no sequence to bind. On macOS that chord reaches the browser as back/forward.
 
 # ── Editor ──
 if command -v nvim >/dev/null 2>&1; then