docs(wiki): vision-service hardening backlog + boot-migration data-seed note

Two unrelated leftover wiki edits from earlier sessions:
- NEW concepts/vision-service-hardening.md: the prioritised to-do list from the
  2026-07-02 code + security reviews of apps/vision/ (DoS gaps, unauthenticated/
  operator-writable model weights, 0.0.0.0 default bind). Cross-linked from
  opencv-anpr-service.md ("consult before touching this service").
- container-deployment.md: note that a boot-time migration can be a DATA SEED
  (e.g. an RBAC permission granted to the operator role via INSERT OR IGNORE),
  and that a built-in-role grant does not auto-apply to a custom role.

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

wiki/decisions/container-deployment.md

@@ -92,7 +92,12 @@ prod); `ENV=dev` switches to the dev override.
 - **Migrations at boot, not at build.** The DB lives on a mounted volume (`/data`), so the entrypoint
   runs them against the live file via a **drizzle-kit-free** runtime migrator
   (`packages/db/scripts/migrate-runtime.mjs`, using `drizzle-orm/.../migrator` — drizzle-kit is a
-  devDep, pruned from the prod bundle). Idempotent: a restart re-applies nothing.
+  devDep, pruned from the prod bundle). Idempotent: a restart re-applies nothing. **A migration is
+  not only schema** — it can also be a **data seed** (e.g. a new RBAC permission granted to the
+  `operator` role via `INSERT OR IGNORE`, so a new operator capability reaches the booth on the next
+  deploy). The whole `@parking/db` package ships in the bundle (no `files` allowlist), so every
+  `drizzle/*.sql` is present in the image. NB a permission seeded to the built-in `operator` role does
+  NOT auto-apply to a **custom** role — an admin toggles it in Setup → Roles.
 - **JWT_SECRET** must be a real value at deploy — `auth.ts` rejects anything `<32` chars or matching
   `change.?me|insecure|dev-only`, so the dev compose default is a benign 32-char string, not a
   "dev-only…" placeholder (which would crash boot).