fix(wordeck): pre-existing test drifts + L-2 cleanup vor Deploy

- tests cards→wordeck rebrand-drift: app-name in health/search/tools/dsgvo,
  envelope to.app + service-key env-var WORDECK_DSGVO_SERVICE_KEY
  (war: CARDS_*). Test-Suite jetzt 83/83 grün.
- dsgvo.ts: ENV-Name auf WORDECK_DSGVO_SERVICE_KEY (war CARDS_*) — passt
  zum Test-Setup + wordeck-Branding
- decks.ts (web): generateDeckFromImage routet URL-only-Pfad auf
  generateDeck, File-Upload-Pfad wirft klaren Fehler (Server-Route
  existiert nicht). UI-Komponenten unverändert
- migrate-db-to-events.ts: Stub als „nicht benötigt" markiert.
  Wordeck-Production hat keine User-Daten in den obsoleten Tabellen;
  Marketplace-Decks (cardecky-User) leben in eigenem pgSchema und
  sind vom Cutover nicht betroffen

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

apps/api/scripts/migrate-db-to-events.ts

@@ -1,42 +1,35 @@
 /**
- * Migration-Skript für den Big-Bang-Cutover L-2 (2026-05-20).
+ * Migration-Skript-Stub für DB→Event-Sync (L-2, 2026-05-20).
  *
- * Liest pro User alle Decks + Cards + Reviews aus der Wordeck-DB und
- * publiziert sie als event-sourced Append-Sequence an
- * sync2.mana.how/sync/wordeck. Idempotent über `idempotencyKey =
- * 'migration:<row-id>:<event-type>'`.
+ * **Aktueller Status (2026-05-20): NICHT BENÖTIGT.**
  *
- * Verwendung (immer dry-run probieren bevor echter Run):
+ * Wordeck-Production hat keine User-Daten in den (jetzt obsoleten)
+ * wordeck.decks/cards/reviews-Tabellen. Die einzigen aktiven Daten
+ * sind die öffentlichen Marketplace-Decks des cardecky-Plattform-Users,
+ * die in `marketplace.public_decks` + `marketplace.deck_versions` leben
+ * und vom Big-Bang nicht betroffen sind.
+ *
+ * Dieses Skript bleibt als Bauplan stehen, falls künftig vor einem
+ * weiteren Cutover (z.B. Schema-V2-Migration) ein DB→Events-Lift
+ * gebraucht wird. **Bei Reaktivierung dringend Code-Review +
+ * Dry-Run-Tests, das Skript ist heute ungetestet.**
+ *
+ * Offene Implementation-Punkte falls Reaktivierung kommt:
+ *   - `mintToken()` braucht entweder Service-Key-Token-Mint in mana-auth
+ *     (gibt's heute nicht) oder Service-Key-Auth-Mode in mana-sync
+ *     (gibt's heute nicht) — beides Plattform-Arbeit
+ *   - Encryption: Plaintext-Migration ist akzeptabel solange Trust-
+ *     Domain stimmt; Re-Encrypt nach User-Login als Folge-Task
+ *
+ * Verwendung (sobald aktiviert):
  *
  *   pnpm tsx scripts/migrate-db-to-events.ts --dry-run [--user-id <id>]
  *   pnpm tsx scripts/migrate-db-to-events.ts --commit  [--user-id <id>]
  *
- * Ohne --user-id wird über alle User iteriert. --dry-run gibt Counts
- * aus ohne POST. --commit POSTet tatsächlich.
- *
  * Voraussetzungen:
  *   - DATABASE_URL gesetzt (Wordeck-DB)
  *   - MANA_SYNC_URL (default https://sync2.mana.how)
- *   - MANA_SERVICE_KEY (für service-side User-JWT-Mint oder per-User-Token)
- *   - User-JWTs: Skript ruft mana-auth-`POST /api/v1/service/mint-token`
- *     mit Service-Key + user_id für temporäre JWT (Service-Key-Pattern,
- *     siehe shared-auth)
- *
- * Encryption: Daten werden im **Plaintext** an sync2 gesendet — wir
- * haben keinen User-Master-Key zur Migration-Zeit. Server speichert
- * sie als wire-format string (NoOp-kompatibel). Wenn der User sich
- * später einloggt + Vault-Key bootstrappt, kann ein Re-Encrypt-Pass
- * folgen. Für den Big-Bang akzeptieren wir Plaintext-Migration, weil:
- *   - die Daten waren vorher schon in Postgres plaintext
- *   - der Sync-Server liegt in derselben Trust-Domain (Mac Mini)
- *   - User kann nach Login encrypted-Versionen drüberspielen
- *
- * **Status: Skript-Stub, ungetestet.** Vor echtem Run:
- *   1. Code-Review durch Till
- *   2. Snapshot von mana_sync_v2.wordeck.* + Wordeck-DB
- *   3. Dry-run für 1-2 User
- *   4. Manuelle Verifikation des sync2-States
- *   5. Erst dann --commit
+ *   - MANA_SERVICE_KEY (für Token-Mint)
  */
 
 import { eq, sql } from 'drizzle-orm';