Phase 3.5a: MAR and Vitals timeline lenses, Kimi K2.6 as extraction default, DocView memory-leak fix

rmerk's Phase 3.5a PR adds MAR and Vitals views over the existing `document_events` log, switches the extraction model to NVIDIA Catalog's Kimi K2.6 (vision), and addresses a memory leak in the extraction page that caused RSS to grow without bound on large Epic PDFs.

discoverysummarization

The MAR and Vitals views follow the Phase 3 Timeline pattern: new routes reading document_events jsonb columns directly, no schema migrations required. The medications and vitals shapes are now pinned in the extractor prompt, and each lens runs dedicated coercion validators that drop malformed entries before they reach the UI. Because both columns already live on events as jsonb, this slice is additive without touching the database.

The default extraction model swaps from Claude to NVIDIA Catalog's Kimi K2.6 (vision), routed through a new provider-dispatching extraction entry point with retry and backoff. rmerk documents four tuneable knobs for multi-hour Epic runs: main-loop concurrency, retry budget, reaper timeout, and async mode. These exist specifically because a 3,000-page document at real throughput will hit rate limits, and the defaults are calibrated to be conservative.

The memory leak fix targets a specific failure mode: on the extraction page with a 3,000-page PDF, repeated zoom, resize, bbox highlight changes, and document switches were retaining PDF.js worker-side caches that the JS GC couldn't reclaim, so RSS climbed per interaction rather than plateauing. The fix calls destroy() on the document and per-page cleanup() on the right transitions, and stops bbox-highlight updates from triggering a full re-render of every page canvas. The underlying issue - eagerly rendering all pages at once, which produces roughly 10 GB of canvas pixels at 1x scale on a 3K-page document - is explicitly deferred to a page virtualization follow-up. This PR makes memory plateau rather than grow; it doesn't make the footprint small.

Phase 3.5b (Labs, needs a new jsonb column) and 3.5c (Bills, likely a new charges table) are deferred. The PR is open; build, type-check, lint, and backend extraction tests are green. End-to-end verification against a real Epic ebook with DevTools heap profiling was not done by the agent and is flagged as manual work.

So what Worth a look if you're already running the Phase 2 extraction pipeline and want MAR and Vitals views without new migrations. The Kimi K2.6 default swap is only relevant if you care about extraction model choice. The memory-leak fix is worth pulling independently if your fork has the DocView + large PDF combination - the plateau behavior change is real even if the root cause isn't addressed yet.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?