feat(devices): radar presence input + button-light output on the controller

Model the entry button (I1) and a Hikvision radar (I2) as named children of the
access controller, and drive the button's 12V lamp on a spare relay.

- Radar = the existing relays[].presenceInput one-car-one-ticket gate, now labelled
  presenceKind: loop|radar. A radar may idle opposite the button, so add a per-input
  active-level override: relays[].presenceActiveLow -> driver inputActiveLow set,
  inverting just that terminal (pure helper inputActive()). The Dingtian has one
  board-wide resting level otherwise.
- AuxOutputDevice.setAux(channel,on) capability on the device interface (Dingtian
  latch) so business logic drives a NON-barrier lamp through the interface. Barriers
  still only pulseOpen — barrier-not-a-door preserved.
- ButtonLightController: subscribes to the radar input edge + the camera lane status
  and drives a 3-state lamp — radar+car=solid, radar-only=blink (~1Hz), else off.
  Fails OFF on host loss/error; de-duped. A radar detection never opens a barrier on
  its own (advisory; threat model).
- SetupWizard: presence kind + active-low + a button-light relay picker; sq+en i18n.

Tests: button-light.test.ts (truth table + blink + fail-OFF + de-dupe),
access-dingtian.test.ts (active-level inversion). Workspace build+lint+test green
(158 server tests). Wiki: hikvision-radar, button-light-indicator + updates.

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V

wiki/entities/dingtian-relay.md

@@ -46,11 +46,28 @@ see [[dingtian-vs-mqtt]].
 
 ## Driver & config API
 
-The `dingtian` driver ([[device-registry]]) implements three capabilities:
-`AccessControlDevice` (relay pulse/latch over UDP), `InputDevice` (read inputs + poll-based
-press/release events ~50 ms), and `PreconditionDevice` (below). Config fields include a separate
-**`httpPort`** — the device's web/config API is on a configurable HTTP port (default **80**),
-distinct from the UDP control port 60001.
+The `dingtian` driver ([[device-registry]]) implements:
+`AccessControlDevice` (relay pulse/latch over UDP), `AuxOutputDevice` (latch a NON-barrier output —
+see below), `InputDevice` (read inputs + poll-based press/release events ~50 ms), and
+`PreconditionDevice` (below). Config fields include a separate **`httpPort`** — the device's
+web/config API is on a configurable HTTP port (default **80**), distinct from the UDP control port
+60001.
+
+### Spare relays + aux outputs (`setAux`)
+
+A 4-input board typically has spare relays once the entry/exit barriers are wired. These drive
+**non-barrier indicators** — e.g. the entry button's 12 V lamp (see [[button-light-indicator]]).
+Business logic drives them through the device-agnostic `AuxOutputDevice.setAux(channel, on)` (a
+latch), **never** the barrier `pulseOpen`. The [[barrier-not-a-door]] rule doesn't apply to an aux
+output (it never gates a vehicle), so holding/blinking it is fine.
+
+### Per-input active level (`presenceActiveLow` / `inputActiveLow`)
+
+Inputs are normalised against ONE board-wide resting level (`inputRestingHigh`). When a sensor (e.g.
+a [[hikvision-radar|radar]]) idles **opposite** the button, list its terminal as active-LOW —
+sourced from each relay's `presenceActiveLow`, merged into the driver's `inputActiveLow` set — so
+that one input is read inverted while the button keeps the board default. (`inputActive()` is the
+pure helper; push-mode uses the device's own `ilu.active_level` instead.)
 
 ### Precondition: input_link_relay must be OFF