docs(wiki): note log:read perm + entry presence/cooldown guard in reference pages

Sync the two canonical reference pages with this session's features: local-jwt-auth
gains the new log resource / log:read permission in the RBAC grid (links app-logs);
first-run-setup notes the one-car-one-ticket presence-loop/cooldown guard the admin
configures on a relay (links entry-double-press).

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

wiki/concepts/first-run-setup.md

@@ -8,10 +8,11 @@ updated: 2026-06-15
 # First-Run Setup (device selection)
 
 The admin install flow that makes the system **device-agnostic in practice**: on first run, an
-admin adds **controllers** (each declaring its relays — entry/exit/both — and the entry-button
-terminal) and then **readers/cameras/printers** bound to a controller relay, choosing from the
-[[device-registry]] catalog and entering each device's connection config. There is **no lane** —
-the pool-of-spaces model; see [[entry-exit-points]].
+admin adds **controllers** (each declaring its relays — entry/exit/both — the entry-button
+terminal, and the one-car-one-ticket guard: a presence-loop input or a cooldown, see
+[[entry-double-press]]) and then **readers/cameras/printers** bound to a controller relay, choosing
+from the [[device-registry]] catalog and entering each device's connection config. There is **no
+lane** — the pool-of-spaces model; see [[entry-exit-points]].
 
 > Implementation-derived (from `apps/server` + `apps/web`), not the source doc.
 

wiki/entities/local-jwt-auth.md

@@ -37,6 +37,9 @@ Authentication and authorization, kept **fully local** — a direct consequence
   **last user holding admin** — administration can never be locked out of the appliance.
 - `event:void` is a permission, NOT a ledger delete: the append-only signed chain is untouched; the
   permission only gates who may APPEND a void event (there is no void API route yet — forward seam).
+- The grid is **extensible** — adding a feature adds its `resource:action` rows. Latest: **`log:read`**
+  (a new `log` resource) gates the diagnostic-log viewer (`GET /api/logs`); admin holds it, and it's
+  grantable to a diagnostic role. See [[app-logs]].
 - **No privilege escalation through the RBAC system itself.** `role:create`/`role:update` and
   `user:create`/`user:update` are themselves grantable, so a non-admin could otherwise self-escalate.
   Guards (`routes/roles.ts`, `routes/users.ts`): a caller may only put permissions on a role that