HTTP fallback leg (docs/19): e2e scenario 13 + docs

- e2e.py: scenario 13 (http fallback) — drives a full turn over the
  HTTP leg (health + POST /v1/frame + SSE /v1/events, no WS) and
  asserts the user echo lands on the SSE stream in < 1.5 s.
- ws_probe.py --http: prints '== user echo in X.XXs' (the docs/19
  sendable-in-fallback timing assertion) alongside the existing
  health/POST/SSE output; same assertion flags as the WS leg.
- docs: 19 status flipped to implemented; 09-pairing-security §9.4
  cross-reference (second door, same lock: token + device allowlist,
  64 KiB cap, rate limit, optional TLS, unauthenticated /v1/health);
  13-testing manual scenario 15 + automated pointers.

docs/09-pairing-security.md

@@ -60,6 +60,14 @@ security principal (the token is).
   - **Reverse proxy / tunnel** (Caddy, Cloudflare Tunnel, ngrok): terminate TLS
     at the edge, forward WS to `127.0.0.1:8790`.
   - **Public bind** (`0.0.0.0`) + WSS + strong token — last resort.
+- **HTTP fallback leg (docs/19):** the gateway also serves the same frames
+  over plain HTTP (`ANDROID_HTTP_PORT`, default 8791) for the app's
+  fallback transport. It is a *second door with the same lock*: the same
+  Bearer token (constant-time `verify_token`) + the same device allowlist
+  (`X-Iris-Device`), the same 64 KiB body cap and per-device rate limit as
+  the WS. Optional TLS via `ANDROID_HTTP_CERT` / `ANDROID_HTTP_KEY`.
+  `GET /v1/health` is unauthenticated by design (liveness only — it must
+  not reflect tokens, device ids, or versions).
 - The app stores the server URL + (for self-signed) the pinned cert fingerprint
   in secure storage.