wiki: Dingtian relay decision, HTTP-over-MQTT, unmanned direction

- dingtian-relay: relay+input controller (4ch on hand). Inputs are decoupled
  from relays (configurable via input_link_relay) — solves the
  access-controller-button-flow blocker the UHPPOTE couldn't. Full protocol from
  the SDK (UDP string control :60001, `00` status parse, input_link_url push,
  multicast discovery). Driver + hardware test still to build.
- dingtian-vs-mqtt: use direct HTTP/UDP now; MQTT skipped (broker = extra infra
  + failure mode + overkill at one-host/few-devices scale) but kept for later
  multi-lane scale.
- autonomous-direction: record the roadmap to fully unmanned (no booth) and how
  it reshapes the threat model (operator-fraud -> unattended-machine threats),
  makes host-in-the-loop entry mandatory, and raises fail-state stakes.
- threat-model: note the unmanned shift. index + log.

gitignore the vendor SDK (dingtian/, 71MB of binaries/examples) — reference
only, protocol captured in the wiki.

wiki/concepts/threat-model.md

@@ -35,3 +35,9 @@ The controls that actually address insider/operator fraud are different in kind:
 The same reframing recurs at the device layer: the [[uhppote-controller]]'s real problem is
 unauthenticated commands ([[uhppote-udp-protocol]]), addressed by detection
 ([[event-log-ingestion]]) or prevention ([[esp32-custom-controller]]).
+
+> **Direction shift:** the system is heading toward **fully unmanned operation** — no operator, no
+> booth ([[autonomous-direction]]). That removes the booth-operator as the *primary* adversary, but
+> swaps in **unattended-machine threats** (tailgating, plate spoofing, physical tampering, forced
+> entry). The append-only signed log + reconciliation controls carry over; the emphasis moves from
+> "catch the cashier" to "trust the automated record and detect tampering."