docs(spec): add phase-2 marker (GPU OCR) + distributed-GPU notes

Tracks #253. Captures the decision to use marker (GPU-accelerated)
instead of tesseract for the phase-2 extract-ocr command, and sketches
three options for distributing OCR across the 3-machine GPU pool
(laptop 5070 Ti / rig 4090 / rack 3060).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/specs/2026-04-23-comments-extraction-design.md

@@ -124,13 +124,39 @@ Bodies stay on disk. The view is for filtering/aggregation; downstream classifie
 
 ## Out of scope
 
-- OCR execution (phase 2, separate command, separate dependency `pytesseract` + system `tesseract`)
+- OCR execution (phase 2, separate command — see "Phase 2 OCR" below for the plan)
 - Position classification (#254)
 - Coordination detection (#255)
 - Dashboard (#256)
 - Re-extracting already-completed `combined.md` files (force re-run = `rm combined.md` then re-run)
 - Refactoring `prisma/export.py` PDF extraction
 
+## Phase 2 (deferred): GPU-accelerated OCR via marker
+
+When we build the `extract-ocr` command, **use [marker](https://github.com/datalab-to/marker)** rather than tesseract. Reasons:
+
+- ~1.8K OCR-needed PDFs (5-10% of the 18.5K total) → at marker's ~1-3s/page on GPU, the whole OCR pass finishes in ~3-5 hours. Tesseract on CPU would be a multi-day job.
+- Marker output is markdown (preserves headings, tables, lists) — drops cleanly into the existing `combined.md` body sections.
+- Built on Surya for layout + OCR; MIT-licensed; PyTorch backend.
+- Alternatives considered: docling (IBM, slightly higher quality but heavier deps), MinerU (fast but ~10GB VRAM peak). Marker is the best fit at our PDF volume + hardware.
+
+Replace `pytesseract` in the dependencies; add `marker-pdf` instead. The phase-2 command shape stays as designed (`stack comments extract-ocr [--docket ...] [--limit ...]`).
+
+### Distributed GPU across machines (open question)
+
+Available hardware:
+- **laptop** — RTX 5070 Ti
+- **rig** — RTX 4090
+- **rack** — RTX 3060 (12GB) [where the comments backfill currently runs]
+
+For phase-2 OCR we'd want a way to fan workload across all three. Options to investigate when we get there:
+
+1. **Pull-based queue** — small task server (Redis/SQLite + a tiny FastAPI) hands out comment-dir batches; each box runs a worker that pulls, processes locally, writes `combined.md` back to a shared FS or S3-compatible store (we already have rustfs).
+2. **Ray / Dask cluster** — overkill for this volume, real ops cost.
+3. **Just three independent CLI runs with `--docket` partitioning** — dumbest approach, lowest setup cost; assign different docket prefixes per machine, sync the resulting `combined.md` files via rustfs.
+
+Lean toward option 3 unless we end up needing this for the long-term (#254/#255 inference workloads might justify option 1).
+
 ## Dependencies added
 
 - `pymupdf>=1.24` (AGPL-3.0)