docs(deploy): COOKIE_SECURE=0 runbook for the plain-HTTP appliance

Documents the deploy-time requirement that the cookie fail-safe fix (7629d5d)
introduced: the LAN appliance serves the SPA same-origin over plain http, where a
Secure cookie is never sent — so it MUST set COOKIE_SECURE=0 or operators can't log
in. A TLS deploy leaves it unset.

- wiki/concepts/disk-os-hardening.md: new "Deploy-time server configuration (runbook)"
  section listing the security-load-bearing env (JWT_SECRET, EVENT_SIGNING_KEY,
  COOKIE_SECURE=0) with the why + the network-scoped justification.
- wiki/entities/local-jwt-auth.md: corrected the stale "Secure when NODE_ENV=production"
  cookie line to the Secure-by-default / opt-out model.
- wiki/log.md: entry.

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

wiki/entities/local-jwt-auth.md

@@ -51,8 +51,12 @@ Authentication and authorization, kept **fully local** — a direct consequence
 
 The SPA never sees the JWT. Login (`POST /api/auth/login`) verifies bcrypt and sets two cookies:
 
-- **`parking_token`** — the JWT, **HttpOnly + SameSite=Strict** (+ `Secure` when
-  `NODE_ENV=production`). JS can't read it; `@fastify/jwt` reads it from the cookie, not the
+- **`parking_token`** — the JWT, **HttpOnly + SameSite=Strict**, and **`Secure` by default**
+  (fail-safe — a forgotten env can only make cookies more restrictive, never drop the flag).
+  `Secure` is dropped ONLY for a deliberate opt-out: `COOKIE_SECURE=0` (the plain-HTTP LAN
+  appliance — see [[disk-os-hardening]] deploy checklist) or `NODE_ENV=development`. (Was keyed
+  off `NODE_ENV=production`, which silently leaked cookies on an appliance that forgot to set it
+  — corrected 2026-06-21.) JS can't read it; `@fastify/jwt` reads it from the cookie, not the
   `Authorization` header.
 - **`parking_csrf`** — a random token, **readable** by JS. The JWT also carries a matching `csrf`
   claim. On every mutation the SPA echoes the cookie in the **`X-CSRF-Token`** header; the guard