feat(quick-260909-mir): dkv-Testlage herstellen, Konfigurationspfade binden, Planer-Pfad benennen

- apps/api/src/dkv/dkv.service.spec.ts (neu): Zwei-Klienten-Nachweis nach
  dem Muster aus groups.service.spec.ts/tender-triage.service.spec.ts —
  dieser Bereich hatte vorher KEINE Testdatei (Befund J). 7 Testfaelle
  decken getConfigForApi, saveConfig (Zugangsdaten-Erhaltung), testConnection,
  die Verarbeitungsstrecke und den bewusst ungebundenen Planer-Startpfad ab
- dkv.service.ts: loadConfig(tenantId?) in zwei Methoden geteilt —
  loadConfig(tenantId) [Pflicht-Mandant, gebunden] und die neue, eigene
  Methode loadAnyActiveConfigForScheduler() [bewusst UNGEBUNDEN, eigener
  Kopfkommentar mit beiden Zustaenden]. getConfigForApi/saveConfig/
  testConnection/_runPipeline binden je EINEN Klienten pro Methode
  vollstaendig ueber forTenant()
- dkv-scheduler.service.ts: Kopfkommentar fortgeschrieben (beide Zustaende,
  Praezedenzfall, Unsymmetrie), Aufruf auf loadAnyActiveConfigForScheduler()
  umgestellt — an der Ablauflogik des Planers nichts geaendert
- .planning/WINDOWS.md: Eintrag #21 (deviation) fuer die benannte Altlast
  des Planer-Startpfads angelegt
- docs/mandantentrennung-zugriffsklassifikation.md: dkvModuleConfig-Zeile
  auf den jetzt gemessenen Stand "gemischt" nachgezogen (Rule 3 — noetig,
  damit rls-access-inventory.spec.ts nach der Aufteilung von loadConfig()
  gruen bleibt; die uebrigen zwei dkv-Zeilen und die Uebersichtstabelle
  bleiben Aufgabe 3 vorbehalten)
- Falsifizierungsnachweis erbracht: getConfigForApi's erster gebundener
  Client probeweise durch this.prisma ersetzt, genau Test 1 wurde rot
  (6 andere blieben gruen), Rueckbau zurueckgenommen, Dateien identisch
  zum Ausgangsstand bestaetigt

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR

apps/api/src/dkv/dkv-scheduler.service.ts

@@ -21,10 +21,33 @@ const CronJobClass: new (cronTime: string, onTick: () => void) => { start(): voi
  * module config. (Research Pattern 7: Dynamic Cron Job; Pitfall 4: ScheduleModule
  * must be registered in AppModule — done in Plan 01.)
  *
- * Multi-tenant note (v1): On init, the scheduler loads the first active
- * DkvModuleConfig row via findFirst(). For single-tenant deployments this
- * is always the correct config. Multi-tenant scheduling (one cron job per
- * active tenant) is deferred to a future plan.
+ * Multi-tenant note (v1): On init, the scheduler loads config via
+ * `DkvService.loadAnyActiveConfigForScheduler()`, which pulls the first
+ * active DkvModuleConfig row via findFirst() — same underlying query as
+ * before, now split into its own named method (260909-mir).
+ *
+ * BLEIBT bewusst UNGEBUNDEN (WINDOWS #21 Etappe 2, 260909-mir, Befund D —
+ * volle Begruendung im Kopfkommentar von
+ * `DkvService.loadAnyActiveConfigForScheduler()` und im Abschnitt
+ * "Bereich dkv" von docs/mandantentrennung-etappe2-fehlerrichtung.md).
+ * Zwei Zustaende, beide gehoeren genannt:
+ *
+ * - HEUTE bereits falsch, nicht nur ungenau: bei mehreren Mandanten wird
+ *   EIN beliebiger bedient, die uebrigen NIE — und ist ausgerechnet die
+ *   gezogene Zeile inaktiv, registriert der Planer gar nichts, obwohl ein
+ *   zweiter Mandant aktiv waere.
+ * - NACH DEM SCHARFSCHALTEN (Etappe 4, WINDOWS #18) verstummt dieselbe
+ *   Abfrage zusaetzlich: sie liefert dann `null`, und die Protokollzeile
+ *   unten ("no active config found") ist auf einer frischen Installation
+ *   der Normalfall — sie alarmiert deshalb niemanden, obwohl ein
+ *   tatsaechlich eingerichteter Mandant nicht bedient wird.
+ *
+ * Fuer single-tenant deployments (heute der einzige produktive Fall) ist
+ * dieselbe Abfrage stets die korrekte Config. Multi-tenant scheduling
+ * (poll-once-fan-out-many, ein Cron-Auftrag je aktivem Mandanten) ist die
+ * in 07-04 zurueckgestellte Mehrmandanten-Planung und bleibt eine
+ * Funktionsaenderung fuer eine kuenftige Phase, kein Bindungsumbau dieses
+ * Plans.
  *
  * The DkvController calls `setInterval()` after saving config so the cron job
  * reflects any admin change immediately — without a service restart.
@@ -56,8 +79,10 @@ export class DkvSchedulerService implements OnModuleInit {
    */
   async onModuleInit(): Promise<void> {
     try {
-      // loadConfig without tenantId → findFirst (v1 single-tenant)
-      const config = await this.dkvService.loadConfig();
+      // Bewusst uebergreifender Planer-Startpfad (WINDOWS #21) — siehe
+      // Kopfkommentar dieser Klasse und von
+      // DkvService.loadAnyActiveConfigForScheduler().
+      const config = await this.dkvService.loadAnyActiveConfigForScheduler();
       if (config?.isActive && config.tenantId) {
         this.activeTenantId = config.tenantId;
         this.setInterval(config.pollIntervalMin, config.tenantId);