Dingtian input HTTP-push to backend (no polling)

The device pushes button events to the backend via its Input Link URL feature;
the backend decides. No polling — the chosen entry architecture.

packages/devices:
- dingtian driver: configureInputPush() writes the device's input_link_url
  config (per-input server/port/path, en=1, active-LOW, plain HTTP) so each
  input HTTP-GETs the backend on press/release. Extracted #readConfig/#writeConfig
  (with the required command:setconfig injection + post-write reset tolerance).

apps/server:
- routes/devices.ts: public GET/POST
  /api/devices/dingtian/:deviceId/input/:n/{on,off} — translates a device push
  into an internal device event. Not behind cookie/CSRF (machine call from the
  device); trust comes from the signed event log, not this request.
- device-events.ts: internal EventEmitter bus so the entry flow subscribes to
  input events without coupling to HTTP. Wired into the server.

Verified on hardware: configured the device, then real presses on all 4 inputs
pushed to the backend (input N on+off, source = device IP). No polling.

wiki: device-input-flow concept (path + trust model for the flat/no-VLAN
network); dingtian-relay updated; index + log.

wiki/entities/dingtian-relay.md

@@ -61,11 +61,27 @@ settings our flow depends on.
 > the POST returns/looks like success but silently does nothing (and the device may reset). With it,
 > POST returns `{"status":0}` and the change sticks. JSON node order must be preserved.
 
+## Input push (no polling) — the chosen architecture
+
+The device **pushes** button events to the backend; the backend decides. **No polling.** The
+driver's `configureInputPush()` writes the device's `input_link_url` config to point each input at
+the backend: input N HTTP-GETs `…/api/devices/dingtian/<deviceId>/input/<N>/on` (and `/off`) on
+press/release. The backend ([[fastify]] route `routes/devices.ts`) translates each push into an
+internal device event ([[device-input-flow]]); the entry flow then prints a ticket and commands
+the relay via UDP. See [[device-input-flow]] for the full path + trust model.
+
+> The input-poll path in the driver (`onInput`) remains as a dev/fallback aid, but **push is the
+> real path** — lower latency, and it can be authenticated (the device supports Basic/Digest +
+> HTTPS on the push), unlike the open UDP control direction.
+
 ## Status — VERIFIED on hardware (DT-R004, sw V3.1.5461A, 10.0.10.172)
 
 - ✅ status read (`0000:1111:4`), relay pulse, input press/release events (active-LOW, idle HIGH).
-- ✅ **`input_link_relay` disabled via the driver** → confirmed: pressing an input now reports the
-  event and **fires NO relay** (`0000` after presses). The [[access-controller-button-flow]] blocker
-  is **solved** — host-in-the-loop entry (`button → host → ticket → host opens relay`) works.
-- ⬜ Next: input HTTP-push endpoint (device `input_link_url` → backend), and wiring the entry flow
-  (input event → print ticket → `pulseOpen`). Polling works today; push is the lower-latency path.
+- ✅ **`input_link_relay` disabled via the driver** → pressing an input reports the event and
+  **fires NO relay** (`0000` after presses). The [[access-controller-button-flow]] blocker is
+  **solved**.
+- ✅ **Input HTTP-push end to end** — configured the device via `configureInputPush()`, then real
+  button presses (all 4 inputs) **pushed to the backend** (`/input/N/on` + `/off` per press,
+  source = the device IP). No polling. Host-in-the-loop entry (`button → backend → ticket →
+  backend opens relay`) is real.
+- ⬜ Next: wire the actual entry flow (input event → signed event + print ticket → `pulseOpen`).