Klarstellen: provisioning bleibt getrennt durch Schlangennamen, nicht durch Redis-Datenbanken

Durchsicht hat nachgewiesen: die Verbindungen redis und provisioning in
config/queue.php lesen beide dieselbe, nirgends gesetzte
REDIS_QUEUE_CONNECTION und landen im selben physischen Redis. Getrennt sind
sie allein durch die Schlangennamen und die explizite --queue-Einschraenkung
jedes Arbeiters. Der Kommentar ueber der command-Zeile haelt das jetzt fest,
damit niemand provisioning in diese Liste aufnimmt, im irrigen Vertrauen auf
eine Datenbankgrenze, die es nicht gibt.

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

docker-compose.yml

@@ -73,6 +73,16 @@ services:
     # `default` — die drei Mail-Schlangen liefen still ohne Fehlermeldung voll,
     # weil niemand sie abholt. `default` bleibt am Ende: dort laeuft alles, was
     # keine Mail ist, und es darf durch diese Aenderung nicht verhungern.
+    #
+    # `provisioning` gehoert NICHT in diese Liste. Die Verbindungen `redis` und
+    # `provisioning` in config/queue.php lesen beide dieselbe (nirgends
+    # gesetzte) REDIS_QUEUE_CONNECTION und landen damit im selben physischen
+    # Redis — es gibt keine eigene Datenbank, die trennt. Getrennt sind sie
+    # allein durch die Schlangennamen und dadurch, dass jeder Arbeiter sich per
+    # --queue ausdruecklich auf seine eigenen beschraenkt. Wer `provisioning`
+    # hier ergaenzt, laesst diesen Arbeiter lautlos Provisionierungsauftraege
+    # mitverarbeiten — in einem Container ohne den Netz-Namensraum, den diese
+    # Auftraege brauchen.
     command: php artisan queue:work redis --queue=mail-direkt,mail-wichtig,mail-ruhig,default --tries=3 --timeout=90
     volumes:
       - .:/var/www/html