devices: pool-of-spaces model — drop lane, per-relay direction

A parking lot is one pool of spaces with a flexible set of entry/exit
points — no "lane". Direction is a property of each RELAY inside an access
controller; readers/cameras bind to a controller relay and inherit it.

Schema:
- drop `lane` from ledger_events, device_events, sessions
- rename lane_devices -> devices (no lane/direction columns)
- access config.relays=[{relay,direction,button?}]; reader/camera
  config.controllerId+relay binding
- fresh 0000_baseline migration (history reset; dev data was throwaway)

Signed ledger:
- remove `lane` from canonicalize(); bump signer keyId sw-hmac-v1 -> v2
  (v1 events won't verify under v2 — intentional, gated per-event by keyId)

Server:
- new device-resolve.ts (replaces lane-map.ts): relayForButton,
  relayForDevice, firstRelayByDirection, devicesByDirection
- entry-flow: button terminal -> its relay; exit/permit: reader's bound
  relay; dispatcher resolves the bound relay + inherited direction
- camera snapshots fire by direction site-wide, async, never block open
- DeviceConfig widened to nested JSON for relays[]

Web:
- wizard: no lane selector; add controllers (relay map + entry-button
  terminal) first, then bind readers/cameras/printers to a controller relay

Wiki: new entry-exit-points.md (replaces lane-direction); reworked
entry-exit-readers, parking-session, first-run-setup, device-registry,
append-only-event-chain, device-events; removed stale lane/LaneMap mentions.

wiki/entities/gee-qr-er80.md

@@ -65,9 +65,9 @@ barrier. ([[device-input-flow]] is the analogous push pattern; this one also ret
 - The read flows were refactored to **return a `ReadOutcome` { accepted, direction, reason }** so the
   endpoint's reply reflects the real accept/reject (the dispatcher decides AND opens the barrier via
   the flows). A fire-and-forget reader ignores the outcome.
-- **Lane mapping:** the endpoint keys the reader's `lane_devices` id off the device **serial
-  (`cjihao`)** for now — so assign the reader with `lane_devices.id = <serial>`. Refine when the
-  setup wizard models the reader's server-side identity properly.
+- **Reader identity:** the endpoint matches the device **serial (`cjihao`)** against each reader's
+  `config.serial` to find its `devices` row; the dispatcher then resolves the relay that row is
+  **bound** to (`config.controllerId` + `relay`) and opens it. See [[entry-exit-points]].
 - Verified via inject: valid permit QR → `status:1` + open; re-scan → permit exit (still valid);
   unknown QR → `status:0`; reader on a barrier-less lane → `status:0`.
 
@@ -84,8 +84,9 @@ from 10.0.10.7   (referer: http://www.fondvision.com — the OEM is Fondvision)
 - **PATH carries the configured "server language" EXTENSION:** this unit is set to **JSP**, so it
   GETs **`/qa/mcardsea.jsp`** — NOT `.php`. Our endpoint was registered at `.php` only → it would
   have 404'd the real reader. **Fixed:** the route now registers `php/jsp/asp/aspx/cgi`.
-- **`cjihao` = `H05M2AFA`** is the device **serial** — the value our endpoint keys the lane on. So
-  assign the reader with **`lane_devices.id = "H05M2AFA"`** (+ an access device on the same lane).
+- **`cjihao` = `H05M2AFA`** is the device **serial** — the value our endpoint matches against the
+  reader's `config.serial`. So assign the reader with **`config.serial = "H05M2AFA"`** and bind it
+  to a controller relay.
 - **`mjihao` = 1** (device id). `cardid` = the scanned barcode (`52020056`). `status=11`.
 - The reader **beeped on the vendor reply with `status:0`** — so it acts on the reply; `0` =
   invalid/1-beep as documented. A matching permit/session will return `status:1` → 2-beep accept.
@@ -94,14 +95,14 @@ from 10.0.10.7   (referer: http://www.fondvision.com — the OEM is Fondvision)
 
 A dedicated **`gee-qr-reader`** driver ([[device-registry]], reader category) models the push reader:
 its one config field is **`serial`** (the `cjihao` the device reports). The admin assigns it in the
-[[first-run-setup|setup wizard]] like any device (normal UUID row id) and enters the serial. The QR
-endpoint resolves the lane by **matching `config.serial` to the scan's `cjihao`** — not by row id —
-so no DB hand-editing. Set the reader's server IP/port to this host in the **vendor tool**; assign +
-enter its serial here.
+[[first-run-setup|setup wizard]] like any device (normal UUID row id), enters the serial, and binds
+it to a controller relay. The QR endpoint resolves the reader by **matching `config.serial` to the
+scan's `cjihao`** — not by row id — so no DB hand-editing. Set the reader's server IP/port to this
+host in the **vendor tool**; assign + enter its serial + bind it here.
 
-- Verified via inject: assign `gee-qr-reader` {serial:"H05M2AFA"} on a lane w/ an access device →
+- Verified via inject: assign `gee-qr-reader` {serial:"H05M2AFA"} bound to an access relay →
   a `.jsp` scan with that serial + a matching permit QR → `status:1` (2-beep accept) + open; re-scan
-  → permit exit; unknown card → `status:0`; unassigned serial → `status:0` (no lane, graceful).
+  → permit exit; unknown card → `status:0`; unassigned serial → `status:0` (no relay, graceful).
 - Note `tcpip-reader` is the WRONG model for this device (host-connects-out, a stub) — use
   `gee-qr-reader`.