Orbit: no PDF-export affordance — runs burn long tails chasing native renderers

_Context: from a controlled experiment in which eight frontier models (opus, sonnet, gpt, gpt2, gemini-2.5-pro, gemini-3.5-flash, deepseek, haiku) each drove an Orbit session to reanalyze the same RNA-seq dataset (Santana 2023 *C. auris*) on 2026-06-02–04. Evidence quotes are from the per-run `activity.jsonl` logs._

## Problem

When asked for a PDF report, the brain has no supported path and falls back to whichever native renderer it can find — all of which fail in the per-analysis environment.

## Evidence

- **deepseek**: 10+ PDF-generation attempts all failed — `weasyprint` (GTK/Pango missing), `tectonic` (dyld `libicuuc.78` missing), `fpdf2` (Unicode em-dash crash), `cupsfilter` (no filter). The run ended by telling the user to "open the HTML in a browser and Cmd+P" instead of producing a PDF.
- **gpt2** succeeded only after a manual `pypdf`/matplotlib path; **gemini-3.5-flash** and **sonnet** each hand-rolled their own.

## Impact

Medium. PDF is a common final deliverable; today it is a coin-flip that depends on the host's system libraries.

## Proposed direction

Bundle one reliable HTML→PDF path (headless Chromium or `wkhtmltopdf`) and expose it as a documented affordance / skill, so the brain stops probing fragile native toolchains.