fix(scraper): endurecer memoria — PDF cap 15MB en executor, contenido cap 300k chars

Un batch de 20 fuentes concurrentes con un documento de 98k palabras y
varios PDFs grandes mató el pod (OOMKilled, límite 1Gi) el 2026-07-10 en
plena investigación.

- _extract_pdf: cap bajado de 50MB a 15MB, verificado también sobre el
  body real (Content-Length puede faltar); pdfplumber movido a
  run_in_executor (es síncrono y congelaba el event loop, misma clase de
  bug que DDGS) con flush_cache() por página.
- _mark_scraped: contenido truncado a settings.max_content_length
  (300k chars) antes de guardarlo en source_contents — libros enteros
  inflan RAM y DB sin aportar al RAG.

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

src/config.py

@@ -47,6 +47,8 @@ class Settings(BaseSettings):
     request_timeout: int = Field(30)
     request_delay: float = Field(1.0)          # seconds between requests
     min_content_length: int = Field(200)  # chars
+    # Libros/dumps enteros (100k+ palabras) inflan RAM y DB sin aportar al RAG
+    max_content_length: int = Field(300_000)  # chars
 
     # Fuentes opcionales — desactivadas por defecto: la IP del homelab está
     # bloqueada por Reddit (403) y YouTube (transcripts vacíos), eran peso muerto.