Kunde: persönliche Du/Sie-Präferenz pro Mitarbeiter

Neue Tabelle UserCustomerSalutation (PK userId+customerId,
preference 'DU'|'SIE'). Fehlender Eintrag → Fallback auf
Customer.useInformalAddress (Kunden-Default).

Backend:
- customerService: get/set/clearSalutationPreference mit Fallback-
  Logik. Response enthält immer effektive Präferenz + `source`
  ('user' | 'customer-default'), damit die UI den Standard-Text
  anzeigen kann.
- customerController: 3 Endpunkte GET/PUT/DELETE
  /:customerId/salutation-preference. userId aus dem JWT, canAccessCustomer
  greift.

Frontend:
- customerApi: 3 neue Methoden.
- CustomerDetail: neues Feld "Anrede für mich" mit Du/Sie-Toggle
  und Zurücksetzen-Link. Wird nur Mitarbeitern angezeigt, nicht
  Portal-Usern.
- Bestehendes Feld "Anrede per" bekommt Hinweis "Standard für alle
  Mitarbeiter", damit die Semantik der beiden Felder klar ist.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

backend/prisma/migrations/20260704200000_user_customer_salutation/migration.sql

@@ -0,0 +1,18 @@
+-- Per-User-Präferenz "Du"/"Sie" pro Kunde. Fehlender Eintrag fällt auf
+-- den Kunden-Default `Customer.useInformalAddress` zurück. Composite-PK
+-- (userId, customerId) verhindert doppelte Präferenzen pro Paar; Index
+-- auf customerId hilft dem Cleanup, wenn der Kunde gelöscht wird.
+
+CREATE TABLE IF NOT EXISTS `UserCustomerSalutation` (
+  `userId`     INT NOT NULL,
+  `customerId` INT NOT NULL,
+  `preference` VARCHAR(191) NOT NULL,
+  `createdAt`  DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
+  `updatedAt`  DATETIME(3) NOT NULL,
+  PRIMARY KEY (`userId`, `customerId`),
+  INDEX `UserCustomerSalutation_customerId_idx` (`customerId`),
+  CONSTRAINT `UserCustomerSalutation_userId_fkey`
+    FOREIGN KEY (`userId`) REFERENCES `User`(`id`) ON DELETE CASCADE ON UPDATE CASCADE,
+  CONSTRAINT `UserCustomerSalutation_customerId_fkey`
+    FOREIGN KEY (`customerId`) REFERENCES `Customer`(`id`) ON DELETE CASCADE ON UPDATE CASCADE
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

backend/prisma/schema.prisma

@@ -90,6 +90,9 @@ model User {
   customerId         Int?      @unique
   customer           Customer? @relation(fields: [customerId], references: [id])
   roles              UserRole[]
+  // Persönliche Anrede-Präferenz pro Kunde ("Du"/"Sie") – User-Wunsch
+  // 2026-07-04. Fehlender Eintrag = Kunden-Default (Customer.useInformalAddress).
+  customerSalutations UserCustomerSalutation[]
   createdAt          DateTime  @default(now())
   updatedAt          DateTime  @updatedAt
 }
@@ -207,10 +210,35 @@ model Customer {
   // DSGVO: Einwilligungen
   consents             CustomerConsent[]
 
+  // Persönliche Anrede-Präferenzen aller Mitarbeiter zu diesem Kunden.
+  userSalutations      UserCustomerSalutation[]
+
   createdAt            DateTime       @default(now())
   updatedAt            DateTime       @updatedAt
 }
 
+// ==================== USER-CUSTOMER SALUTATION ====================
+// Per-User-Präferenz, ob der eingeloggte Mitarbeiter mit dem jeweiligen
+// Kunden per Du oder Sie ist. Fehlender Eintrag → fällt auf den
+// Kunden-Default (Customer.useInformalAddress) zurück.
+// User-Wunsch 2026-07-04: Stefan kann per Du mit einem Kunden sein,
+// während andere Mitarbeiter denselben Kunden weiter siezen.
+
+model UserCustomerSalutation {
+  userId     Int
+  user       User     @relation(fields: [userId], references: [id], onDelete: Cascade)
+  customerId Int
+  customer   Customer @relation(fields: [customerId], references: [id], onDelete: Cascade)
+  // 'DU' oder 'SIE'. String statt Enum, damit man ohne Migration einen
+  // dritten Wert nachschieben könnte (z.B. 'MIXED' o.ä.).
+  preference String
+  createdAt  DateTime @default(now())
+  updatedAt  DateTime @updatedAt
+
+  @@id([userId, customerId])
+  @@index([customerId])
+}
+
 // ==================== CUSTOMER REPRESENTATIVES ====================
 // Vertretungsbeziehung: Ein Kunde kann die Verträge eines anderen Kunden einsehen
 // z.B. Sohn (representativeId) kann Verträge der Mutter (customerId) sehen