mailbox notify: record that the terminal path is unverified through tmux

Measured on tor-ms22: the layering here is kitty -> tmux (on the host) ->
docker exec -> pi (in the container), with two clients attached to one tmux
session. Test OSC sequences written straight to pi's tty produced no
notification on the remote client; the local client is still unobserved. Most
likely tmux is dropping OSC types it does not implement — reaching the outer
terminal needs tmux's DCS passthrough (ESC P tmux; ... ESC \, inner ESC doubled)
plus allow-passthrough on, which is not the default and is not implemented here.

The point worth keeping is structural, not incidental: the container can see
NEITHER layer. KITTY_WINDOW_ID is absent because docker exec does not forward it,
and TMUX is absent because tmux runs one level further out on the host. So a
containerised client cannot detect the terminal it is speaking to or the
multiplexer it must speak through, and autodetection is not merely unreliable
here — it is blind. Explicit configuration is the only route, which is why the
previous commit added forced kitty/osc777 modes.

No behaviour or defaults changed: in-TUI notify remains the default and the
terminal path stays opt-in. Also flagged the unsettled routing question — a
pane's output reaches every attached client, so a work laptop and a home machine
would both ping from one arriving ask.

extensions/pi/README.md

@@ -343,6 +343,15 @@ which touches the no-`triggerTurn` decision:
   not because it is unreliable. Title and body are stripped of `;` and control
   bytes, so a payload can neither forge an OSC field nor end the sequence early.
 
+  **⚠️ Not yet observed firing through tmux (2026-08-26).** If pi runs inside a
+  multiplexer — e.g. `kitty → tmux on the host → docker exec → pi` — tmux drops
+  OSC sequences it does not implement, so the ping can vanish silently between
+  the container and the human. Reaching the outer terminal needs tmux's DCS
+  passthrough plus `allow-passthrough on`, which is not implemented here yet.
+  Note the client can detect *neither* layer: `KITTY_WINDOW_ID` is not forwarded
+  by `docker exec`, and `TMUX` is unset because tmux runs one level further out.
+  Verify with a hand-written sequence in your own stack before trusting it.
+
   It fires **only when something is due** — the same condition as the delivery
   itself. A ping on an empty poll would train its reader to ignore it, which is
   the failure this whole feature exists to reverse.