Inbox verb stops losing PDFs — the binary lands alongside Jina's markdown, sha256-verified, LFS-tracked; the chat composer grows an upward-opening commands popover so the verb is discoverable from the surface itself

Yesterday `/inbox <url>` shipped and the very first capture exposed the load-bearing failure: the DOL workforce-strategy PDF Jina-extracted into a 5KB markdown stub and the original binary was *gone* — no page-numbered citation, no figure reference, no re-extraction by a better tool, no copy to hand a co-researcher. Today the inbox handler grew a HEAD-probe → URL-suffix → streamed-GET binary downloader behind the same NATS subject; the .pdf lands as a sibling of the .md with a matching dated slug, sha256-verified end-to-end (the response envelope hash matches the on-disk hash, byte for byte), under a per-client `.gitattributes` that LFS-tracks `*.pdf` so the per-client repo's git pack stays sane. Verified live: `/inbox https://insights.hanoverresearch.com/.../Top-Career-Skills-for-2-Year-Grads-2026.pdf?_gl=…` (full Hanover URL with eight tracking params) landed a 1.15 MB PDF (`file` confirms PDF v1.7) next to a markdown index with the `binary_asset:` frontmatter block populated. Same scaffolding extends to docx/pptx/xlsx the moment those become operator pain. While we were in `apps/chat/` we added a small unrelated affordance the inbox verb had been quietly begging for: a Commands popover under the composer that opens *upward*, lists the slash-verb registry, and inserts the chosen verb at the start of the textarea — discoverability for a surface where the only way to know `/inbox` existed was to read the changelog.