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.

apps/server/src/routes/devices.ts

@@ -0,0 +1,54 @@
+import type { FastifyInstance, FastifyRequest } from "fastify";
+import { deviceEvents } from "../device-events.js";
+
+// Inbound device push endpoints. The Dingtian board's "Input Link URL" feature
+// HTTP-calls us when an input (button) fires — no polling. We translate the
+// push into an internal device event; the entry flow decides what to do
+// (print a ticket, then command the relay). See wiki/entities/dingtian-relay.md.
+//
+// AUTH: these are machine-to-machine calls FROM the device, which can't do the
+// SPA's cookie/CSRF auth. They are intentionally NOT behind requireRole. Trust
+// does NOT come from this request — every barrier open is a host decision
+// recorded as a signed event, so an out-of-band/forged open has no matching
+// signed event and shows up as an anomaly (see wiki/concepts/append-only-event-chain
+// and threat-model). A shared-secret check can be layered on later as
+// defence-in-depth; on a flat network it isn't the security boundary.
+
+interface InputParams {
+  deviceId: string;
+  n: string;
+}
+
+export async function deviceRoutes(app: FastifyInstance): Promise<void> {
+  // Dingtian input ON-edge push (button pressed). The device is configured
+  // (via input_link_url) to call this path for each input. GET or POST both
+  // accepted — the device's method is configurable; the URL carries the input.
+  const handler = (edge: "on" | "off") =>
+    async (req: FastifyRequest<{ Params: InputParams }>) => {
+      const { deviceId, n } = req.params;
+      const input = Number(n);
+      app.log.info(`[dingtian:${deviceId}] input ${input} ${edge} (push)`);
+      deviceEvents.emitInput({
+        driverId: "dingtian",
+        deviceId,
+        input,
+        edge,
+        at: new Date().toISOString(),
+        source: "push",
+      });
+      return { ok: true };
+    };
+
+  for (const method of ["GET", "POST"] as const) {
+    app.route({
+      method,
+      url: "/api/devices/dingtian/:deviceId/input/:n/on",
+      handler: handler("on"),
+    });
+    app.route({
+      method,
+      url: "/api/devices/dingtian/:deviceId/input/:n/off",
+      handler: handler("off"),
+    });
+  }
+}