fix(remote): start csh and tcsh login shells without -i -l

A remote host whose login shell is tcsh came up on 1.48.0, when the local
sh rewrote ${SHELL:-/bin/sh} to the Codeman host's shell. Since #770 the
launch reaches the far end verbatim and runs tcsh itself, and tcsh refuses
-i -l -c, -l -c and -i -l, so every stock launch left a dead pane.

The login flags are now picked on the far end, in the shape of
loginShellArgs(): set -- -i -l, cleared for csh and tcsh, then
exec "${SHELL:-/bin/sh}" "$@". The text is one brace group, so
cd <path> && { ...; } still starts nothing when the cd fails. bsd-csh takes
every flag combination, csh is listed because it is tcsh on macOS and the BSDs.

The version probe keeps its one statement: the login shell parses it, not
/bin/sh, so fish and tcsh refuse it either way, as they did on 1.48.0.

Measured with the real builder on a real sshd in a throwaway Debian container
(tcsh 6.24.07, bsd-csh, fish 3.6, bash) and through a fake sshd with
tcsh 6.24.10, fish, zsh, dash and bash, a real Codeman server on tcsh included.
The tcsh disclosure comes out of the docs and the changeset. They keep the two
limits 1.48.0 had too: tcsh has no export, so the PATH bootstrap only prints an
error, and the tmux probe needs a command executable, which Debian lacks.

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

docs/grok-integration.md

@@ -114,7 +114,7 @@ history.
 ## Remote SSH cases
 
 `grok` mode is routed through an interactive login shell
-(`exec "$SHELL" -i -l -c 'grok'`), because sshd's remote-command PATH does not include
+(`remoteLoginShellCommand('grok')`), because sshd's remote-command PATH does not include
 `~/.grok/bin`. Per-session config and `envOverrides` do not cross ssh and are rejected
 rather than silently ignored; use the per-host command override instead. For auth on
 the remote host, `grok login --device-auth` exists for exactly this.

docs/omp-integration.md

@@ -149,7 +149,7 @@ shared nor seeded.
 ## Remote SSH cases
 
 `omp` mode is routed through an interactive login shell
-(`exec "$SHELL" -i -l -c 'omp'`), because sshd's remote-command PATH does not
+(`remoteLoginShellCommand('omp')`), because sshd's remote-command PATH does not
 include `~/.local/bin`. Per-session config and `envOverrides` do not cross ssh and are
 rejected rather than silently ignored; use the per-host command override instead.
 

docs/pi-integration.md

@@ -221,7 +221,7 @@ a Docker case only sees that container's own history.
 ## Remote SSH cases
 
 `pi` mode is routed through an interactive login shell
-(`exec "$SHELL" -i -l -c 'pi'`), because sshd's remote-command PATH does not
+(`remoteLoginShellCommand('pi')`), because sshd's remote-command PATH does not
 include npm's global bin on most hosts. Per-session config and `envOverrides` do
 not cross ssh and are rejected rather than silently ignored; use the per-host
 command override instead.

docs/remote-sessions.md

@@ -152,17 +152,20 @@ Key points:
   fish refuses `${SHELL:-/bin/sh}` with status 127, which is a dead pane. A `commands.*`
   override stays one argument on purpose, since it is written for the user's own shell
   (`source` and `[[` work in bash and zsh and die under a dash `/bin/sh`).
-- **Login shells**: POSIX shells and fish work. nushell and elvish cannot run the
-  PATH bootstrap at all, so no override helps. A `remotePath` holding an apostrophe
-  does not start under fish.
-- ⚠️ **A tcsh login shell stopped working in 1.49.0.** tcsh refuses `-l` beside any
-  other flag (``Unknown option: `-l'``), so every stock launch leaves a dead pane. On
-  1.48.0 the local `sh` rewrote `${SHELL:-/bin/sh}` to this host's shell, so such a
-  host ran that shell instead (when its path also exists on the remote) and came up.
-  It now needs a `commands.*` override per mode (`exec claude`). The Create Case
-  form's Remote tab offers codex only, the other modes go through
-  `PUT /api/remote-hosts/:id`, and a `commands.claude` override gives up the
-  `--session-id`/`--resume` pair, so a respawn starts a new conversation.
+- **Login shells**: POSIX shells and fish work, and csh and tcsh do within the limits
+  below. nushell and elvish cannot run the PATH bootstrap at all, so no override
+  helps. A `remotePath` holding an apostrophe does not start under fish.
+- **The login flags are picked on the far end**, the only place the shell is known:
+  the pane command passes `-i -l` unless `${SHELL##*/}` is `csh` or `tcsh`, which get
+  neither. tcsh honors `-l` only as its one flag and exits on `-i -l -c`, `-l -c` and
+  `-i -l` (measured on 6.24), so a tcsh session reads `.tcshrc` and not `.login`. The
+  text is one brace group, so `cd <path> && { …; }` starts nothing when the `cd` fails.
+- **The login shell still parses the ssh line itself**, as it did in 1.48.0, so tcsh
+  has two more limits. It has no `export`, so the PATH bootstrap only prints an error
+  there, and `tmux` and the CLI have to be on a PATH that `.tcshrc` sets. And the tmux
+  prerequisite probe's `command -v tmux` needs a `command` executable: macOS and the
+  BSDs ship one, Debian and Ubuntu do not, so linking a tcsh host there is refused
+  with `could not verify tmux`.
 - Connection options come from the **same `buildSshConnectionArgs(remote)`** as
   the prereq probe; `-t` is inserted right after `ssh -o BatchMode=yes`,
   preserving historical token order.

docs/wiki/Remote-SSH-Sessions.md

@@ -35,11 +35,11 @@ in it expands there, not on the Codeman machine.
 The remote host needs **tmux**. Codeman probes for it when you link the host rather than
 failing later at launch.
 
-The remote login shell can be bash, zsh, dash or fish. Since 1.49.0 **tcsh needs an override**
-for each run mode you use (`exec claude`), because tcsh refuses the flags of a stock launch and
-the pane dies. The Remote tab offers the codex override, the others go through
-`PUT /api/remote-hosts/:id`, and a claude override gives up resuming the same conversation on a
-respawn. nushell and elvish cannot run a remote session at all.
+The remote login shell can be bash, zsh, dash, fish, csh or tcsh. A tcsh session reads `.tcshrc`
+and not `.login`, so set the PATH that finds `tmux` and your agent CLI in `.tcshrc`. The tmux check
+also needs a `command` executable under tcsh: macOS and the BSDs ship one, Debian and Ubuntu do
+not, so linking a tcsh host there stops at `could not verify tmux`. nushell and elvish cannot run a
+remote session at all.
 
 ## What actually runs