feat: Webhook-Warteschlange in Datenbank persistieren

Die Warteschlange liegt nicht mehr im Speicher, sondern in der neuen Tabelle
webhook_queue (Entity WebhookQueueItem, documentId als Primärschlüssel). So
überstehen ausstehende IDs einen Neustart und werden nach dem Boot
weiterverarbeitet.

- Neue Entity + Migration (CreateWebhookQueue); in data-source.ts/Barrel
  registriert. Dev: synchronize legt die Tabelle an; Prod: migrationsRun.
- enqueue nutzt INSERT IGNORE (atomar, race-sicher) -> Dedup über den PK.
- processQueue holt FIFO (createdAt ASC), entfernt die Zeile vor der
  Verarbeitung, arbeitet sequenziell (isProcessing-Guard).
- getStatus/queueSize lesen die DB-Anzahl. Controller awaitet enqueue.
- Unit-Test mit simuliertem FIFO-Repo: Dedup, Remove-on-start, Re-Enqueue,
  No-Parallel (deterministisch).

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

paperless-backend/src/webhook/webhook.module.ts

@@ -5,9 +5,14 @@ import { WebhookQueueService } from './webhook-queue.service';
 import { PaperlessModule } from '../paperless/paperless.module';
 import { AuthModule } from '../auth/auth.module';
 import { Setting } from '../database/entities/setting.entity';
+import { WebhookQueueItem } from '../database/entities/webhook-queue-item.entity';
 
 @Module({
-  imports: [TypeOrmModule.forFeature([Setting]), PaperlessModule, AuthModule],
+  imports: [
+    TypeOrmModule.forFeature([Setting, WebhookQueueItem]),
+    PaperlessModule,
+    AuthModule,
+  ],
   controllers: [WebhookController],
   providers: [WebhookQueueService],
 })