Dingtian: close password-less string-protocol relay-fire hole

The string protocol (UDP 60001) has no password field but can fire relays
("11" = relay 1 on), bypassing relay_pw entirely. Proven on hardware: an
unauthenticated packet opened a relay. harden() had left it enabled "for
status reads".

- #status() now reads via the authenticated binary command (relay cmd 0x00)
  instead of the string protocol, so the string protocol is no longer needed.
- harden() disables the string protocol (udp2.p=255). BEST-EFFORT: firmware
  V3.6J's config API silently refuses to disable udp2 (the device web UI can),
  so it's not part of the blocking verify -- harden() re-checks and returns a
  warning instead of throwing. After a web-UI disable, the attack is dead and
  binary control/status still work (verified on hardware).
- HardenResult gains an optional `warnings[]`; the assign route surfaces them
  to the admin and logs them.
- Corrected the false comment claiming relay_pw stops an attacker (it is
  defence-in-depth on plaintext UDP, not a boundary).
- Thread localAddress through the driver's UDP/HTTP calls so a multi-homed
  host sources device traffic from the device-facing NIC.
- Device web login (webUser/webPassword) is no longer redacted from setup
  state -- it's an operational credential for the admin-only device area;
  pushPassword/relayPassword stay machine-only.

Wiki: document the vuln + fix, the firmware caveat, and the out-of-band
actuation gap (the log captures host actions only; reconciliation vs. an
independent witness is the real control and is not yet built).

wiki/entities/dingtian-relay.md

@@ -79,17 +79,42 @@ the relay via UDP. See [[device-input-flow]] for the full path + trust model.
 > real path** — lower latency, and it can be authenticated (the device supports Basic/Digest +
 > HTTPS on the push), unlike the open UDP control direction.
 
+### What it pushes vs. doesn't (logging)
+
+- **Inputs (buttons): YES, pushed.** Input changes are HTTP-pushed via `input_link_url` and now
+  land in the host's signed [[append-only-event-chain]] as `input_received` events (bus →
+  `EventLog`). That is the audit trail for "a button fired."
+- **Relay / barrier opens: NO push, no log.** The device has **no event log of its own** and does
+  not report when a relay fires — relay control is one-way UDP that the *host* initiates. So
+  "the barrier opened" is not something to scrape from the device. The host records what it
+  *commanded* (a future `barrier_open_command` event); a relay open with **no matching signed
+  host event is itself the anomaly** to alarm on ([[threat-model]]). Do not treat the Dingtian as
+  a log source — it is a dumb relay+input board; the host is the source of truth.
+
 ## Hardening (`harden()`) — and why HTTP auth is not a boundary here
 
 On assign the driver runs `harden()` (the [[device-registry|HardenableDevice]] capability):
 1. **`relay_pw`** — set a random relay password so binary relay commands (UDP 60000) need it.
-2. **Disable unused channels** — set `p:255` on rs485/can/tcp×2/mqtt; keep only UDP1 binary
-   (relay control) + UDP2 string (status read).
+2. **Disable EVERY other channel** — set `p:255` on the string protocol (udp2), rs485, can,
+   tcp×2, mqtt; keep **only** UDP1 binary, which carries `relay_pw` for both control AND status.
 3. **Rotate the `admin`/`admin` web login** — `GET /userset.cgi?<old_u>&<old_p>&<new_u>&<new_p>&`
    (response `&0&…&` = success, verified on hardware). The new password is stored back in
    config (`webUser`/`webPassword`) so a re-run can rotate again (the device checks the *old*
    creds). This step is **best-effort** — a failure logs and does not fail the assign.
 
+> ⚠️ **The string protocol (udp2) is a password-less relay-fire path — the original `harden()`
+> left it ENABLED "for status reads", which was a real hole.** The Dingtian string protocol has
+> NO password field and can fire relays (`"11"` = relay 1 on, `"21"` = off, `"11*"` = jog).
+> **Proven on hardware**: sending `"11"` to UDP 60001 with no credentials opened relay 1,
+> completely bypassing `relay_pw`. Fixes: (a) status reads moved to the **authenticated binary
+> read** (relay command `0x00`) so the string protocol is no longer needed; (b) `harden()` now
+> sets `udp2.p=255` to disable it. **Firmware caveat (V3.6J):** the CONFIG API silently refuses
+> to disable udp2 — it accepts the write, reboots, and clamps it back — even though the device's
+> **web UI can** disable it. So the udp2 disable is **best-effort + warns** (it is NOT part of the
+> blocking verify); if it doesn't stick, `harden()` returns a warning telling the admin to flip
+> UDP2 off in the device web UI. Verified: after the web-UI disable, the `"11"` attack gets no
+> reply and the relay stays off, while authenticated binary control/status still work.
+
 > ⚠️ **The device CGI API is UNAUTHENTICATED.** Verified on hardware: `GET /api/v2/config.cgi`,
 > `/`, and even `/userset.cgi` all return **200 with no credentials**. The `admin`/`admin` login
 > gates only the interactive **browser UI** — the CGI control plane (read/write full config, fire