fix(security): push-endpoint SSRF guard + tmux name validation; document tail-file roots

- M7 (SSRF): add isSafePushEndpoint (https-only; reject internal/loopback/link-local/metadata IPs incl. IPv4-mapped); enforce in PushSubscribeSchema and re-check before webpush.sendNotification. + unit test.
- M1 (command injection): validate tmux session names with isValidMuxName in sessionExists, killSession, and reconcileSessions before they reach a shell call site.
- M5: keep the intentional /var/log + ~/logs log-tail roots (a tested feature) and document the wider read scope in docs/security-architecture.md section 5 instead of dropping it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/security-architecture.md

@@ -306,6 +306,20 @@ injected from API JSON (`innerHTML`), not via `file-raw`, so they are unaffected
 is **defense‑in‑depth, not the primary boundary** — the realpath containment is
 the control.
 
+### SSE log‑tail route — intentional extra read roots
+
+The live file‑tail SSE route (`FileStreamManager`, used to stream a growing log
+into the UI) does **not** use `validateSessionFilePath`; it has its own validator
+with a deliberately **wider** allowlist: the session `workingDir` **plus two
+read‑only log roots — `/var/log` and `~/logs`** — so operators can tail
+system/app logs. `/tmp` is intentionally excluded (world‑writable). Like the
+other routes it `realpath`s the target and re‑checks right before spawning `tail`
+(TOCTOU guard), and it is read‑only. This is the one place the per‑session
+boundary is intentionally relaxed; on a password‑protected remote deployment an
+authenticated user can therefore read `/var/log` and `~/logs` outside their
+session dir. (Security review M5: this divergence is by design and is now
+documented here rather than silently diverging from the per‑session claim above.)
+
 ### Known limitation — `workingDir` scope
 
 The file‑route boundary is the session's `workingDir`, and `POST /api/sessions`