docs: remote-ssh hangs on a bare sudo — pipe it; record where the dsh update stopped

Found by using the tool for real work rather than by smoke-testing it. A bare
`sudo -n whoami` through ssh_run returns `running` with no output and wedges the
session permanently; the same command piped through `cat` returns everything.
Reproduced on both macOS and Debian, so it is the harness rather than a platform
quirk, and it matters because infra work is sudo work.

The workaround goes in CLAUDE.md where a session will actually hit it. The
proper fix is a protocol change — run the command through a pipe and read
PIPESTATUS — and is deliberately not attempted here.

Also records where the dsh work stopped: the package is updated but the running
web process is still on the old code, left alive on purpose because there is no
LaunchAgent to restart it into.

CLAUDE.md

@@ -62,6 +62,14 @@ It deliberately has **no file transfer and no idempotency**; that is elway's hal
   agreement; coordinate before touching, which is a contractual posture and not a
   security one. `pfi-pve` (10.250.250.31) is deliberately NOT caught by this — the
   denies are host-specific, not a /24 over shared space.
+- ⚠⚠ **A bare `sudo` HANGS the session — always pipe it: `sudo -n <cmd> | cat`.**
+  `ssh_run 'sudo -n whoami'` returns `running` forever with zero output and the
+  session is then permanently `busy`; the piped form returns everything. Measured
+  on both macOS and Debian, so it is the harness and not a platform quirk. Cause:
+  sudo ≥1.9.14 defaults `use_pty` on and relays through its own PTY; with the run
+  frame's stdin on `/dev/null` and stdout on the session PTY the relay never
+  completes, so the completion marker never arrives. A pipe makes stdout a non-tty
+  and sudo skips the PTY. Not yet fixed in our fork.
 
 **Task visibility via task-board.** If the Claude Code session has
 the `task-board` plugin enabled (installed from