feat: platform backbone and field capture, first part (checkpoint)

Platform backbone (plan 2026-10-13-plattform-rueckgrat), reviewed tasks:
- run roles api/worker/job/all with shared startup checks (Task 1)
- schema and migration for DomainEvent, deliveries, JobRun, ThrottlerHit (Task 2)
- audit, notifications and domain events written in the same transaction (Task 3)
- dispatcher with SKIP LOCKED claims, retries and stale release (Task 4)
- worker building blocks: tick, LISTEN/NOTIFY wake-up, health (Task 5)
- worker process and entry points (Task 6)
- throttler counters in Postgres (Task 19)
- separate keys per purpose with key ring (Task 20)
- public origin page without exact location (Task 22)
- shop keys split into read and write (Task 23)
- Kustomize base, components, overlay encry, CI validation (Task 26)

Field capture T3 (plan 2026-10-13-t3-erfassung-am-stand), reviewed tasks:
- brood frames, read endpoints, apiary overview and offline pack
- network basics, offline queue v3, navigation sheets, form building blocks
- new inspection with last-time hints and weather, varroa per day,
  treatment prefill, apiary page with round
- inspection photo (Task 10) is implemented, review pending

Not rolled out. Remaining tasks follow in later commits.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

ApiCore-Backend/Dockerfile

@@ -1,6 +1,10 @@
 # syntax=docker/dockerfile:1
 
-FROM node:22-alpine AS builder
+# Base-Image per Digest gepinnt (node:22-alpine, Multi-Arch-Index vom
+# 2026-09-23): ein Rebuild zieht nie ungeprueft ein neues Image. Ein Update
+# ist ein bewusster Commit mit neuem Digest, ermittelt per
+#   docker buildx imagetools inspect node:22-alpine
+FROM node:22-alpine@sha256:0a7108bf6c7bf5de370ffb1a3ed6be93d405b43ff159f681a8d18c0e2bc2e402 AS builder
 WORKDIR /app
 COPY package.json package-lock.json ./
 RUN npm ci
@@ -14,16 +18,16 @@ RUN npx prisma generate
 RUN npx eslint "{src,test}/**/*.ts" && npm run typecheck && npm test -- --ci
 RUN npm run build
 
-FROM node:22-alpine AS runtime
+FROM node:22-alpine@sha256:0a7108bf6c7bf5de370ffb1a3ed6be93d405b43ff159f681a8d18c0e2bc2e402 AS runtime
 ENV NODE_ENV=production
 WORKDIR /app
 COPY package.json package-lock.json ./
 RUN npm ci --omit=dev
 COPY --from=builder /app/dist ./dist
 COPY --from=builder /app/generated ./generated
-# schema.prisma, migrations/ und prisma.config.ts: noetig fuer
-# `npm run migrate:deploy`, das der Container beim Start selbst ausfuehrt
-# (siehe CMD unten). seed.ts selbst wird NICHT zur Laufzeit ausgefuehrt -
+# schema.prisma, migrations/ und prisma.config.ts: noetig fuer den
+# initContainer `migrate` (siehe Kommentar ueber CMD unten).
+# seed.ts selbst wird NICHT zur Laufzeit ausgefuehrt -
 # `npm run build` kompiliert es vorab zu dist/seed.js (siehe
 # tsconfig.seed.json), das schon in ./dist enthalten ist. Frueher lief
 # `ts-node prisma/seed.ts` direkt im Container: der TypeScript-Compiler
@@ -31,9 +35,19 @@ COPY --from=builder /app/generated ./generated
 # fuehrte zu sporadischen OOM-Crashes beim Start.
 COPY --from=builder /app/prisma ./prisma
 COPY --from=builder /app/prisma.config.ts ./prisma.config.ts
-EXPOSE 3001
+# 3001: HTTP der api-Rolle. 3002: /health der worker-Rolle.
+EXPOSE 3001 3002
 USER node
-# migrate deploy ist idempotent und nutzt einen DB-seitigen Advisory-Lock,
-# seed ist idempotent per Unique-Constraint auf User.email (siehe seed.ts) -
-# beides unproblematisch bei mehreren gleichzeitig startenden Pod-Replicas.
-CMD ["sh", "-c", "npm run migrate:deploy && npm run seed && node dist/main.js"]
+# Migration und Seed laufen nicht mehr hier, sondern als initContainer im
+# Pod (deploy/k8s/components/backend-roles): `migrate` in api und worker
+# (`node node_modules/prisma/build/index.js migrate deploy`, idempotent mit
+# DB-seitigem Advisory-Lock), `seed` nur in der api (`node dist/seed.js`,
+# idempotent per Unique-Constraint auf User.email). Scheitert die Migration,
+# startet der neue Pod nicht und der alte laeuft weiter. Der Hauptprozess
+# startet ohne Prisma-CLI; worker und Jobs ueberschreiben das Kommando
+# (dist/worker.js, dist/cli.js <job>), die Rolle waehlt APICORE_ROLE.
+# Dieses Image darf darum nur zusammen mit components/backend-roles live
+# gehen (Runbook Schritt 3). Fehlt APICORE_ROLE, bricht der Start in
+# Produktion absichtlich ab. APICORE_ROLE nicht von Hand in ein Deployment
+# ohne die initContainer setzen: dann liefe keine Migration.
+CMD ["node", "dist/main.js"]