Inline attachment text into the LLM payload when reading .msg or .eml

easterbrooka extended the email-reading path so the model sees attachment content alongside the message body - no manual detach-and-reupload needed. Pure read-side enrichment; the UI and storage layer are unchanged.

The core addition is a shared text dispatcher that accepts a filename and raw bytes and returns extracted text by suffix, covering PDF, DOCX, TXT, XLSX, and nested .eml/.msg. Inline images and unrecognised types are skipped rather than errored. Three explicit caps keep large mailboxes from blowing up the context window: 50k characters per attachment, 400k characters total across an email, and a recursion ceiling of three levels for nested messages before falling back to a placeholder.

Both the .eml and .msg branches gained dedicated for-LLM parser variants. They reuse the existing parsers but filter out the inline-related parts mailparser flags (signature logos, inline images) so those don't bleed into the prompt. Per-attachment failures are caught individually rather than aborting the whole email read.

The chat tool's document-reading branch was switched to the new variants, so the enrichment is live anywhere the model opens an email from the project. easterbrooka shipped 16 vitest cases covering the dispatcher and both parser variants, reports the backend suite at 133/133, and notes a clean TypeScript compile before the same-minute self-merge.