feat(app): send PDFs as their text and open attached files from the timeline

[iamnbutler]

Part of #26. Follows #469.

A PDF in the composer (dropped, picked, or pasted) is no longer refused. The app extracts its text with pdf.js and sends it as a TextFile, so it reaches every model, and is stored, exactly like a text file. A sent file's timeline block now opens its contents.

Design decision. I picked the simplest option that works the same for local, hosted, and peer channels, with no second store and no stored-format change:

• Provider document input: not possible. pi-ai 1.0.0's UserMessage content is only TextContent | ImageContent, and its Anthropic/OpenAI conversions turn every non-text block into an image block, so a PDF can't reach a model natively without changing pi.
• Placing the file in the lane: rejected. It needs a new request and a workspace write path, it fails while a hosted channel's workspace is offline, it shows up as an untracked file in the lane's Diff, and the agent still has no tool that reads PDFs on macOS.
• Text extraction in the app (shipped): a PDF becomes { name: "x.pdf", text }. The protocol, <attachment> storage, the 1.5 MB budget, and channel checks from feat: send text files from the composer to the agent #469 are unchanged, so there's no migration and older hosts and clients read it as text.

Changes

• apps/app/src/attachments.ts: if a file's type is application/pdf, the app lazy-loads pdfjs-dist (6.3.289, Apache-2.0, added to the ui catalog). Its worker is a separate ~1.3 MB asset, so the main bundle doesn't grow. Pages are separated by blank lines. A PDF with no text layer is refused with "x.pdf has no text to read; scanned PDFs can't be attached", and a corrupt one with "x.pdf couldn't be read as a PDF". Page text is read through the stream's reader, not getTextContent, because that call async-iterates a ReadableStream, which WebKit doesn't support and which threw in the desktop's engine (both the modern and the legacy pdf.js builds). PDFs are detected by MIME type only, so a withdrawn PDF that comes back to the composer as its text (text/plain) is read as text.
• Opening files from the timeline (packages/ui): the existing timeline file block now gets the file's text through Content.File.text. It shows a line count and, when clicked, opens the existing FileView (components/file/file-view, with Shiki highlighting by file name) in the shared Dialog, the same way timeline images open. The block's cache key includes the text, since names can repeat across messages.
• Prompt: the attachments line now says a block holds "the whole file, or a PDF's extracted text".
• Docs: docs/architecture.md records the attachment design and its limits.

Limits

• Scanned PDFs, images inside PDFs, and layout are lost. Other binary files (zip, docx, xlsx, …) are still refused.
• The 1.5 MB budget counts bytes, not tokens. One large file can be bigger than the model's context. In testing, Keynote's multilingual license PDF (2.9 MB file, ~1 MB of text) came to 466K tokens against Haiku's 200K limit. That run fails, and so does every later run in the chat, until the message is deleted (deleting it fixed the chat). This also applies to large text files since feat: send text files from the composer to the agent #469. I left it unguarded and listed it in Support non-image uploads in the composer #26: the app doesn't know the model's context window, and any byte-to-token guess would be speculative.

Smoke-tested with a source host on an isolated ACE_HOME/ACE_CONFIG_HOME (ace serve --loopback), the built app, and real anthropic/claude-haiku-4-5 runs. The app was driven in headless Playwright WebKit and Chromium, attaching through the composer's file input:

• WebKit and Chromium: sent a generated PDF. Haiku answered from its text ("The codename is BLUE HERON."), and the block showed "report.pdf · 3 lines".
• WebKit: clicking the block opened the dialog with the extracted text in FileView.
• A drawing-only PDF and random bytes named .pdf were refused with the messages above.
• A .txt attachment still works.
• Real PDFs (Keynote license, Xcode acknowledgments) were extracted (12,930 and 10,718 lines) and sent under the byte budget. Then they hit the context limit described above; deleting both messages made the chat answer again.
• bun types and bun run ci pass.
• Not tested: the native desktop window and file picker (the Mac's GUI session was locked, so desktop tools couldn't capture it), and hosted or peer channels. Those paths carry the same TextFile as feat: send text files from the composer to the agent #469 and nothing on them changed.

Built in Ace

Built with Claude Code outside Ace, in a session already running there; no Ace gap involved.