Event log: resolve input_received lane from the firing device

Replace the hardcoded lane: 0 on input_received events with a real
device->lane lookup. A new LaneMap caches lane_devices.id -> lane,
built at startup and refreshed by the setup routes on assign/unassign.
An unmapped device logs lane: -1 + a warning (0 is a real lane) and is
still recorded faithfully (append-only chain).

source stays null for raw inputs by design: it's an IdentitySource
(how a vehicle was identified), not a device field; device provenance
remains in identity. Documented both in the wiki.

wiki/log.md

@@ -288,3 +288,12 @@ guarantee. Recorded in [[dingtian-relay]] (new Hardening section).
 - Verified on hardware (192.168.1.100): harden set login to a chosen pw; device then rejects
   admin/admin (&2&) and accepts the chosen pw (&0&). UDP2 warning surfaced as designed.
 - Updated [[dingtian-relay]].
+
+## [2026-06-15] update | input_received lane resolution + source semantics
+- Wired device→lane resolution: `LaneMap` (`apps/server/src/lane-map.ts`) caches
+  `lane_devices.id → lane`, refreshed by setup routes on assign/unassign. `input_received`
+  events now carry the firing device's lane instead of a hardcoded `lane: 0`. Unmapped device →
+  `lane: -1` + warn (0 is a real lane; never mis-stamp).
+- Documented that `source` stays null for raw inputs by design (it's an IdentitySource, not a
+  device field); device provenance is in `identity`.
+- Updated [[append-only-event-chain]].