feat: platform backbone and field capture complete (checkpoint)

Platform backbone (plan 2026-10-13-plattform-rueckgrat), all tasks reviewed:
- webhooks with delivery table, retries and stable delivery id
- calendar handlers; a finished task removes its Outlook event
- tasks, automations, inspections, varroa, treatments, feedings,
  harvests, colonies, wintering, stock and bottling record domain events
  in the same transaction; legacy post-commit calls removed
- row locks through one helper (lockRowForUpdate, lockRowsForShare,
  lockRowsForUpdate)
- job framework with JobRun, cli exit codes, cleanup, task templates,
  daily evaluation, hourly app-backup and the rekey job
- system API and page "Verwaltung > System" with retry
- @nestjs/schedule removed, guard tests against in-process schedulers

Field capture T3 (plan 2026-10-13-t3-erfassung-am-stand), all tasks reviewed:
- inspection photo offline without metadata
- bulk capture for treatments, feedings and varroa (backend + frontend)
- offline stand mode with service worker, offline pages and packs
- offline session, cold start and logout on shared devices

Docs: ARCHITECTURE.md assumptions and sections updated, TASKS.md.
Gates: backend lint, typecheck, 1770 unit, 420 e2e, build, no schema
drift; frontend lint, typecheck, 913 tests, build. Not rolled out.

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

docs/superpowers/plans/2026-10-13-plattform-rueckgrat.md

@@ -952,6 +952,7 @@ it('POST /tasks leaves a TaskCreated event whose calendar and webhook deliveries
   - kein Commit
 
 ---
+**Carry-forward (Orchestrator, aus Review Task 8):** Sobald die direkten `calendarSync.enqueue`/`cancel`-Aufrufe entfernt sind, deckt ein e2e-Fall den echten Weg ab: Aufgabe erledigen → `TaskCompleted` → Dispatcher → Handler `calendar-sync.task` → Outbox-Eintrag → `processOutbox()` löscht das Graph-Event und setzt `SKIPPED`.
 
 ### Task 10: Automationen als Handler
 
@@ -1243,7 +1244,7 @@ it('task-templates creates the due task once even when run twice', ...);
 ---
 
 **Carry-forward (Orchestrator, aus Reviews der Tasks 3, 19):**
-- `cleanup` löscht zusätzlich abgelaufene `ThrottlerHit`-Zeilen (`expiresAt < now()`, SQL-Uhr).
+- `cleanup` löscht zusätzlich abgelaufene `ThrottlerHit`-Zeilen (`expiresAt < now()` UND `blockedUntil` ist NULL oder `< now()`, SQL-Uhr – sonst würde eine aktive Fehlversuchs-Sperre der API-Schlüssel aufgehoben; Throttler-Name der Sperre siehe ERP-Branch `failed-attempt-limiter.ts`).
 - Benachrichtigungen über `recordForPermission` bei gescheiterten Jobs werden dedupliziert (z. B. eine je Job und Tag), sonst meldet der stündliche `app-backup`-Check jede Stunde.
 - `cli.ts` ruft wie `main.ts` zuerst `resolveRole` und `assertStartupEnvironment` auf.
 
@@ -1952,12 +1953,15 @@ curl -sI -H "Authorization: Bearer $TOKEN" -H "Accept: application/vnd.oci.image
 - Rückweg: vorigen Digest zurücksetzen und die Komponenten deaktivieren. Die Migration ist additiv, das alte Image läuft weiter.
 
 **Schritt 4 – Schlüssel trennen (Freigabe)**
-1. `kubectl -n apicore create job rekey-dry-$(date +%s) --from=cronjob/apicore-job-rekey-dry-run` → Zähler prüfen, `failed: 0`.
-2. `kubectl -n apicore create job rekey-$(date +%s) --from=cronjob/apicore-job-rekey` → `JobRun` `Erfolgreich`. Ein zweiter Lauf meldet `rekeyed: 0`.
-3. MFA-Login testen, Webhook-Testzustellung prüfen.
-4. „Jetzt sichern“: neues Backup mit den neuen Schlüsseln.
-5. Erst danach `JWT_ACCESS_SECRET` und `JWT_REFRESH_SECRET` rotieren und `kubectl rollout restart deploy/apicore-backend deploy/apicore-worker`. Alle Sitzungen enden einmal, das ist gewollt.
-- Rückweg vor Punkt 5: alte Werte zurück, Altchiffrate bleiben lesbar. Nach Punkt 5 gibt es keinen Rückweg für Altchiffrate, darum die Prüfungen in 1–4.
+Voraussetzung: Schritt 3 ist live, api und worker laufen mit `MFA_ENCRYPTION_KEY`/`WEBHOOK_ENCRYPTION_KEY`, `JWT_ACCESS_SECRET` ist noch der alte Wert (nur er öffnet die Altchiffrate).
+1. `kubectl -n apicore create job rekey-dry-$(date +%s) --from=cronjob/apicore-job-rekey-dry-run` → in „Verwaltung > System“ bzw. `JobRun`: `Erfolgreich`, Zähler `mfa.failed`/`webhook.failed` = 0; `mfa.rekeyed` + `webhook.rekeyed` + `webhook.plaintextSealed` ist die Zahl der umzustellenden Werte. Scheitert der Dry-Run: Pod-Log nennt je Zeile ID und Grund. `unknown key id` → fehlenden `*_PREVIOUS` setzen; `ciphertext failed authentication` bei einem Altwert → JWT-Secret wurde schon geändert, betroffene Nutzer richten MFA neu ein bzw. Webhook neu anlegen. Erst mit `failed: 0` weiter.
+2. `kubectl -n apicore create job rekey-$(date +%s) --from=cronjob/apicore-job-rekey` → `JobRun` `Erfolgreich`. `changedMeanwhile` > 0 ist ein harter Stopp, kein Erfolg: die App hat diese Zeile inzwischen selbst neu geschrieben, der Job hat sie bewusst nicht angefasst (sie kann noch mit dem alten Schlüssel versiegelt sein). Dry-Run aus 1 wiederholen (und bei Bedarf den Lauf), bis alle Zähler 0 sind, erst dann rotieren. Bei `failed` > 0 endet der Lauf immer `FAILED`, die Zähler stehen im Fehlertext; betroffene Zeilen behalten ihren Wert.
+3. Noch einmal den Dry-Run aus 1: `mfa.rekeyed`, `webhook.rekeyed`, `webhook.plaintextSealed`, `changedMeanwhile` und `failed` = 0. Der Dry-Run öffnet auch Zeilen, die schon den aktuellen Schlüssel tragen (ein beschädigter Wert zählt als `failed`); nur der echte Lauf überspringt sie ungeöffnet. Bricht ein Lauf ab (Pod weg), einfach wiederholen – umgestellte Zeilen werden übersprungen.
+4. MFA-Login testen, Webhook-Testzustellung prüfen.
+5. „Jetzt sichern“: neues Backup mit den neuen Schlüsseln (ältere, JWT-versiegelte Backups sind nach Punkt 6 nicht mehr einspielbar).
+6. Zügig danach `JWT_ACCESS_SECRET` und `JWT_REFRESH_SECRET` rotieren und `kubectl -n apicore rollout restart deploy/apicore-backend deploy/apicore-worker`. Alle Sitzungen enden einmal, das ist gewollt.
+- Rückweg vor Punkt 6: alte Werte zurück, Altchiffrate bleiben lesbar (umgestellte Werte öffnen nur mit den neuen Schlüsseln – die neuen Schlüssel darum nie verwerfen, sondern höchstens als `*_PREVIOUS` behalten). Nach Punkt 6 gibt es keinen Rückweg für Altchiffrate, darum die Prüfungen in 1–5.
+- Später (eigene Freigabe): den Klartext-Rückfall in `openWebhookSecret` entfernen, wenn der Dry-Run `webhook.plaintextSealed: 0` zeigt.
 
 **Schritt 5 – HPA einschalten (Freigabe)**
 - `components/api-hpa` aktivieren, diff, apply.