feat(fetch): process PDF content as markdown

[chaliy]

What changed

Fetchkit now converts text-based PDF responses to Markdown through a new ordered ContentProcessorRegistry. The built-in PdfProcessor uses local pdf-inspector processing, reports pages that need OCR, and keeps unsupported binary responses metadata-only.

Custom callers can replace the processor registry while retaining all built-in URL fetchers.

Why

PDF handling was coupled to generic binary rejection, so useful document text could not reach LLM callers. URL fetchers are the wrong extension point because reliable PDF identification happens after the HTTP response.

Before / After

Before:

{"content_type":"application/pdf","error":"Binary content is not supported..."}

After, from the CLI smoke test against the W3C dummy PDF:

{
  "content_type": "application/pdf; qs=0.001",
  "format": "markdown",
  "content": "## Dummy PDF file\n",
  "metadata": {"extraction_method": "pdf_inspector"}
}

Risk

• Medium
• PDF parsing adds CPU/memory work and a new parser dependency. Input/output remain bounded by max_body_size, parsing runs off the async runtime, and concurrent PDF processing is capped at two documents. Parser-internal expansion remains documented as an accepted threat-model risk.
• Scanned/image-only pages are not OCRed; responses surface pdf_requires_ocr and suggest use_ocr.

Checklist

• Unit tests are passed
• Smoke tests are passed
• Documentation is updated
• Specs are up to date and not in conflict

Validation: cargo fmt --all -- --check, workspace Clippy with warnings denied, cargo test --workspace, warning-free workspace docs, release build, live fetcher example, CLI PDF fetch, and MCP initialize/tools-list smoke.