Allow the address the service binds to as a Host value

The deployment listens on 192.168.123.14 and TrustedHostMiddleware rejected that same
address, so every request by IP returned a bare 400 Invalid host header - including
/api/health, which is indistinguishable from the service being down. It has cost this
project twice.

Found when the first pairing attempt from 192.168.123.238 came back 400 with no body
and no logged detail. The pairing code was fine and went unspent; the request never
reached the route.

Both umbratrans.bdmurphy.me and 192.168.123.14 are now allowed. The 0600 on the env
file is unchanged, and the correction is recorded in the alignment doc's transport
note so the audio node is not sent looking for a service outage.

docs/data-model-alignment-v1.md

@@ -897,9 +897,12 @@ Arbitrary nested JSON survives intact. The example above stores
 `raw->speaker_name_agreements` as `{"dealhunter": [61, 64, 97], "last_dwarf": [93, 68, 71]}` —
 checked, not assumed.
 
-**Transport note.** Use the hostname and no `Host` header is needed. If you reach the
-controller by IP address instead, you must send `Host: umbratrans.bdmurphy.me` or every
-request returns `400` — including `/api/health`, which makes a healthy service look dead.
+**Transport note.** Use `http://192.168.123.14:8442` directly. Both that address and
+`umbratrans.bdmurphy.me` are accepted Host values as of 2026-10-03; before then the
+service bound to `192.168.123.14` while rejecting requests to it, so *every* request by
+IP returned `400 Invalid host header` — including `/api/health`, which makes a healthy
+service look dead. If you see a bare `400` with no JSON body, suspect the Host header
+before anything else.
 
 ### 10.7 What the response tells you