docs(cherimoya): fill in missing README + attribution references

[jmschrei]

The README predates Cherimoya, and a later pass patched it in incompletely — so it was still missing from commands, tables, and attribution. This fills the remaining gaps.

Every item was verified against the code or by running the command, not pattern-matched.

README

Gap	Fix
Both download_pertrack_backgrounds loops omitted cherimoya	added; ran all 8 oracles, all return 1
"all seven oracles" / "does all 7" / "other 5 oracles"	corrected to 8 / 7
chorus setup --oracle cherimoya absent entirely	added; name is valid per EnvironmentManager.list_available_oracles()
Model-specific details had no Cherimoya section	added; geometry matches mcp/server.py::ORACLE_SPECS and oracle.sequence_length (2,114 in / 1,000 bins / 1 bp); both documented load paths executed on GPU; 613,892 params measured
Pick an oracle: GPU recommended, <1 s (GPU)	→ optional, with measured inference-only timings
macOS tables omitted Cherimoya	added as CPU-only
Notebooks table said "All 6"	names the 6; notes Cherimoya is also absent from that notebook
cherimoya_quickstart.ipynb ships but was never referenced	added
"get the identifier field"	Cherimoya returns track_id; Enformer and Borzoi return identifier, Cherimoya returns track_id; ChromBPNet/Sei/LegNet/EPInformer-seq return no track list at all (different response shape)
Backgrounds file-size table said ~154 MB	→ ~162 MB; #163 updated ChromBPNet there but missed Cherimoya

GPU is optional, and the timings

CPU was verified working with the GPUs hard-masked (CUDA_VISIBLE_DEVICES="", torch.cuda.is_available() False, 0 devices) across four paths: direct and env mode, each with explicit device='cpu' and with auto-detect. Auto-detect falls back to CPU and returns values bit-identical to explicit cpu.

Inference step only (model load, FASTA extraction and subprocess startup excluded), one H200 vs 8 CPU threads, median of 7–20 warmed runs:

Query	Windows	GPU	CPU	Ratio
1 kb	1	1.2 ms	10.5 ms	8.5×
10 kb	8	2.3 ms	103 ms	45×
100 kb	98	18.4 ms	2.75 s	150×

The ratio is batch-dependent — the GPU amortises windows (1.23 → 0.19 ms/window) while CPU per-window cost climbs (10.5 → 28 ms). So the runtime's flat "~50x slower" warning is only right in the middle of that range. A footnote records the scaling so "optional" doesn't mislead anyone planning a wide scan, plus the ~1e-2 relative CPU/Triton logit divergence (r = 0.99999) measured at the same locus.

Cherimoya is deliberately not added to the macOS Metal list: cherimoya.py resolves cuda-or-cpu only, and platform.py records that the model has no MPS path and that its triton pin has no macOS wheel.

Also

• docs/THIRD_PARTY.md: Cherimoya row (MIT code, CC-BY-4.0 weights) + the "wraps six oracles" count. Satisfies AUDIT_CHECKLIST.md §18 for this oracle. EPInformer-seq attribution is still missing there and is intentionally left alone.
• examples/notebooks/README.md: same "needs a CUDA GPU" overstatement as the main README — needed for speed, not to run.
• No hand-written row was added to the <!-- GENERATED: background-table --> block — it already carries Cherimoya.

Not addressed (pre-existing, flagging only)

• examples/notebooks/README.md says advanced_multi_oracle_analysis "needs all six oracle envs" — stale, and that notebook only uses three (Enformer, ChromBPNet/BPNet, LegNet).
• Its link to README.md#setting-up-oracle-environments is broken; the heading slug is ...-one-by-one.
• README says "22 MCP tools" in two places and "24-tool" in two others.
• The display-rescale table row has an unescaped |effect| that breaks its columns on GitHub.

🤖 Generated with Claude Code