fix(retriever): correctly cap PDF extract actors to avoid CPU oversubscription

[charlesbluca]

Description

Fixes a deadlock introduced when GraphBatchIngestor replaced BatchIngestor as the default batch runtime.
Unlike the legacy path, the graph executor always passes operator classes (not instances) to map_batches, which requires ActorPoolStrategy for all nodes — including PDFExtractionActor, which was previously using TaskPoolStrategy.
Persistent actors hold their CPU allocations continuously, so with the default 12 PDF extract actors × 2 CPUs each, plus ~9 CPUs from other actors in the pipeline (DocToPdf, PDFSplit, PageElements, OCR, UDF, Embed), a single-GPU/32-CPU machine requests 33 CPUs at startup and deadlocks — ReadBinary is immediately backpressured and no data ever flows.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.
• If adjusting docker-compose.yaml environment variables have you ensured those are mimicked in the Helm values.yaml file.

[charlesbluca]

Superseded by #1786