feat(17-01): move TenderEmailConfig ownership from tenant to user

Alert-Postfach gehoert jetzt dem einzelnen Nutzer (userId @unique) statt
dem Mandanten (D-01) — ein zweiter Kollege desselben Mandanten kann sein
eigenes Postfach anbinden. tenantId bleibt denormalisiert (SMTP-Aufloesung,
Herkunftsmarkierung), wird auf create UND update mitgeschrieben.

- Handgeschriebene Migration (prisma migrate dev verweigert die
  nicht-interaktive Shell): befuellt Bestandszeilen mit dem aeltesten
  aktiven Administrator ihres Mandanten, entfernt verwaiste Zeilen ohne
  Administrator, ersetzt die tenantId-Eindeutigkeit durch userId.
  Lokal getestet (0 Bestandszeilen lokal und auf alpha — Zaehlung im
  Task-1-Checkpoint), Index-Ergebnis verifiziert.
- TenderEmailConfigService.getConfigForApi/saveConfig auf userId als
  Schluessel umgestellt; saveConfig nimmt {userId, tenantId}.
- TendersController: email-config-Routen von @Roles(ADMIN,SUPER_ADMIN)
  auf @UseModule('tender-radar') umgestellt (Postfach ist jetzt
  Nutzereinstellung); Route-Reihenfolge vor @Get(':id') unveraendert.
- Neue Seite /modules/tender-radar/my-sources ("Meine Quellen") mit dem
  unveraenderten EmailAlertConfigForm; Hinweistext benennt D-05 (Tender
  bleibt plattform-global — nur wer Quellen einspeist aendert sich).
- tenders.controller.spec.ts an neue Service-Signatur angepasst (Rule 3,
  nicht im Plan gelistet, aber zum Kompilieren/Bestehen erforderlich).

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

apps/api/prisma/migrations/20260812100000_tender_email_config_per_user/migration.sql

@@ -0,0 +1,53 @@
+-- Phase 17 (D-01): das Alert-Postfach ("TenderEmailConfig") gehoerte bisher
+-- dem MANDANTEN (tenantId eindeutig) -- ein zweiter Kollege mit eigenem
+-- Portal-Konto konnte sein Postfach nicht anbinden, weil es bereits eines
+-- fuer den ganzen Mandanten gab. Ab dieser Migration gehoert das Postfach
+-- dem NUTZER (userId eindeutig); tenantId bleibt als gewoehnliches,
+-- denormalisiertes Feld erhalten (SMTP-Aufloesung, Herkunftsmarkierung der
+-- eingelesenen Ausschreibungen -- gleiche Rolle wie in TenderMatch).
+--
+-- Eine bereits vorhandene Postfach-Zeile bekommt dabei den AELTESTEN
+-- AKTIVEN Administrator (ADMIN oder SUPER_ADMIN) ihres Mandanten als
+-- Besitzer zugeordnet, nicht geloescht: die Zeile enthaelt verschluesselte
+-- Zugangsdaten und wurde seinerzeit von genau dieser Rolle angelegt: ein
+-- Loeschen wuerde den laufenden Abruf ohne Vorwarnung stilllegen. Nur wenn
+-- ein Mandant ueberhaupt keinen aktiven Administrator hat, wird die Zeile
+-- entfernt -- sonst waere sie fuer niemanden mehr bearbeitbar, wuerde aber
+-- im Hintergrund weiter abgefragt.
+
+-- 1. Neue Spalte zunaechst ohne Pflicht, damit Bestandszeilen befuellt
+--    werden koennen, bevor NOT NULL erzwungen wird.
+ALTER TABLE "TenderEmailConfig" ADD COLUMN "userId" TEXT;
+
+-- 2. Bestandszeilen: aeltester aktiver Administrator desselben Mandanten
+--    (sortiert nach createdAt, bei Gleichstand nach id, genau einer).
+UPDATE "TenderEmailConfig" AS tec
+SET "userId" = (
+  SELECT u."id"
+  FROM "User" u
+  WHERE u."tenantId" = tec."tenantId"
+    AND u."isActive" = true
+    AND u."role" IN ('ADMIN', 'SUPER_ADMIN')
+  ORDER BY u."createdAt" ASC, u."id" ASC
+  LIMIT 1
+)
+WHERE tec."userId" IS NULL;
+
+-- 3. Zeilen ohne gefundenen Administrator entfernen (kein Mandanten-Admin
+--    vorhanden -- siehe Begruendung oben).
+DELETE FROM "TenderEmailConfig" WHERE "userId" IS NULL;
+
+-- 4. Alte Eindeutigkeitsregel "ein Postfach pro Mandant" aufheben. Der
+--    gewoehnliche Index auf tenantId (TenderEmailConfig_tenantId_idx)
+--    bleibt bestehen -- tenantId wird weiterhin gefiltert (SMTP-Aufloesung).
+DROP INDEX "TenderEmailConfig_tenantId_key";
+
+-- 5. Neue Eindeutigkeitsregel "ein Postfach pro Nutzer" -- erst NOT NULL
+--    setzen, nachdem jede Zeile einen Besitzer hat (Schritte 2/3).
+ALTER TABLE "TenderEmailConfig" ALTER COLUMN "userId" SET NOT NULL;
+
+-- CreateIndex
+CREATE UNIQUE INDEX "TenderEmailConfig_userId_key" ON "TenderEmailConfig"("userId");
+
+-- CreateIndex
+CREATE INDEX "TenderEmailConfig_userId_idx" ON "TenderEmailConfig"("userId");

apps/api/prisma/schema.prisma

@@ -275,9 +275,15 @@ model DkvModuleConfig {
 // DKV invoice inbox). Credentials are encrypted via CalendarCryptoService
 // (same AES-256-GCM iv:authTag:ciphertext format as DkvModuleConfig/
 // SmtpConfig) and excluded from every API response (Safe-Select, T-07-12).
+// Phase 17 (D-01): ownership lives at the USER, not the tenant — each user
+// connects their own alert mailbox, so two colleagues at the same tenant can
+// each run their own inbox in parallel. `tenantId` stays as a denormalized
+// field (SMTP resolution, ownerTenantId tagging on ingested Tender rows) —
+// same role as `tenantId` on TenderMatch, not the ownership key anymore.
 model TenderEmailConfig {
   id                  String   @id @default(uuid())
-  tenantId            String   @unique
+  userId              String   @unique
+  tenantId            String
   protocol            String   @default("imap")    // 'imap' | 'exchange'
   host                String?
   port                Int?
@@ -291,6 +297,7 @@ model TenderEmailConfig {
   updatedAt           DateTime @updatedAt
 
   @@index([tenantId])
+  @@index([userId])
 }
 
 model DkvVehicleMaster {