A demo does not need a tunnel; it needs the laptop's own camera

Asked after the mobile-internet question: could a VPN let the office cameras
be shown in the demo. Three jobs get confused there and only one needs one.

Seeing the estate from anywhere already works and needs nothing - viewer mode
plus LiveHub is exactly that, outbound, no installation and no credential.

Demonstrating recognition is better done on the demo machine's own camera.
`webcam: 0` picks a capture index instead of building an RTSP URL and the
engine has supported it since the first version: CameraStore round-trips it,
source() returns the index, safe_url() reports webcam:0, and
POST /api/cameras {"id":"laptop","webcam":0} has always worked. No screen
offered it - the same gap this repo already records for the customer record
and per-camera tuning. It is now an option in the make picker, and it is the
strongest demo available: real faces, in the room, depending on no network.
A demo pointed at a camera in another building depends on two internet
connections and a tunnel staying up while somebody is talking.

The address and the index are alternatives, not extras: source() takes the
webcam first, so a half-typed host left behind would make the saved camera
describe two things and use one. The scan, the path and the camera password
are hidden for a local camera because none of them mean anything.

A tunnel is still right for one case - running the engine on a remote machine
against the office's own cameras - and still wrong for the product: it is
per-site infrastructure on every shop PC, and it gives head office
network-level access into a customer's LAN, where today we can read a
camera's picture and nothing else.

Also: installing httpx took the suite from 239 passed to 271. The HTTP tests
importorskip it so a bare checkout runs, which means the number at the bottom
of a run is not the number of tests that exist. Added to the dev extra.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj

CLAUDE.md

@@ -3745,3 +3745,60 @@ rule as `artifact` against `no_faces`, and `stale` against `not_connecting`:
   message exists to fix.
 - **With no network at all it still names the cause** and drops the comparison,
   rather than claiming to know which network this machine is on.
+
+## A tunnel for the demo: when it is the right answer, and when it is not
+
+Asked after the mobile-internet question: *"what if we created a secure tunnel
+or vpn, then the cameras in our office can be shown in the demo version too?"*
+
+Three different jobs get confused here, and only one of them needs a tunnel.
+
+**Seeing the estate from anywhere already works and needs nothing.** Viewer
+mode plus `LiveHub` is exactly this: the shop PC pushes frames outbound and any
+signed-in app sees them, from mobile data, a hotel or a customer's office. A
+VPN would add an installation, a credential and a moving part to something that
+already works with none of them.
+
+**Demonstrating recognition is better done on the demo machine's own camera.**
+`webcam: 0` picks a capture index instead of building an RTSP URL, and the
+engine has supported it since the first version — `CameraStore` round-trips it,
+`source()` returns the index, `safe_url()` reports `webcam:0`, and
+`POST /api/cameras {"id":"laptop","webcam":0}` has always worked. **No screen
+offered it**, which is the same gap this file already records for the customer
+record and for per-camera tuning: the API could, the UI could not reach it.
+
+It is now an option in the make picker, and it is the strongest demo available:
+real faces, in the room, instant, depending on no network at all. A demo
+pointed at a camera in another building depends on two internet connections and
+a tunnel staying up while somebody is talking.
+
+**The one case a tunnel genuinely answers** is running the engine on a remote
+machine against the office's own cameras — LAN access to `192.168.1.121` from
+somewhere that is not that LAN. A mesh VPN (Tailscale and similar) does that
+honestly: a subnet router at the office, the client on the demo machine, and
+the address works unchanged. Free at this scale, no port forwarding, no
+exposed camera. Worth using for our *own* office when that is really the goal.
+
+**It is still the wrong answer for the product**, and the reasons are not about
+difficulty:
+
+- It is per-site infrastructure — an account, a node, a key — on every shop PC
+  we ship, to replace something that already works over ordinary HTTPS.
+- It gives head office **network-level access into a customer's LAN**. The
+  current design can read a camera's picture; a VPN can reach the customer's
+  till, their router and everything else on that network. That is a far larger
+  thing to be trusted with, and a far larger thing to have breached.
+- The failure modes are worse and less legible: a tunnel that is down looks
+  like a camera that is down.
+
+So: tunnel for our own office if we want the engine running remotely; nothing
+at all for showing customers their shops; the laptop's own camera for showing
+anybody what the product does.
+
+### And the suite was quietly 32 tests smaller than it looked
+
+Installing `httpx` to check the webcam path took the engine suite from **239
+passed to 271**. `tests/test_api_cameras.py` and its siblings begin with
+`pytest.importorskip("httpx")` so a bare checkout still runs — deliberate, and
+it means the number at the bottom of a run is not the number of tests that
+exist. `pip install -e .[dev]` is the opt-in.