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/concepts/parking-session.md

@@ -28,8 +28,8 @@ adversary is the insider who can edit the database) and the [[append-only-event-
 - A **session** is a **read-model folded from those events** — open when an entry has no matching
   exit, paid when a `payment` event references it, closed when an exit lands. It MAY be cached in
   a table for query speed (dashboards, "cars currently in"), but that cache is **always rebuildable
-  from the chain and never authoritative**. Same pattern as the `LaneMap`
-  ([[append-only-event-chain]]), scaled to the business domain.
+  from the chain and never authoritative** ([[append-only-event-chain]]), scaled to the business
+  domain.
 - **Why this matters:** a mutable `sessions` row that stored "amount owed / paid" would reopen
   exactly the fraud hole the whole system exists to close (operator marks a session paid, pockets
   the cash). With sessions as a projection, "paid" is a **signed `payment` event** an operator
@@ -123,7 +123,7 @@ follow this page and [[tariff]]; the decision is recorded in [[session-model]].
   - **The full transient loop now passes end to end** (verified): entry → quote → pay → exit opens,
     session closed, `verifyChain` ok.
 
-> **Design gap (flagged):** `lane_devices` has **no entry/exit direction** model. Entry is
-> button-driven and exit is read-driven, so they don't currently collide — but a lane with both an
-> entry reader and an exit reader can't yet be distinguished. A lane-direction/role model is needed
-> before multi-reader lanes (relates to [[open-questions]] #1 topology).
+> **Resolved (2026-06-16):** the earlier "no entry/exit direction" gap is closed by the
+> [[entry-exit-points]] model. Direction lives on each access **relay**; readers/cameras bind to a
+> relay and inherit it. The "lane" concept was dropped entirely (pool-of-spaces) — separate in/out
+> readers are distinguished by their relay binding, not a lane.