Add worker support for inline PDF attachment detection and downloading

[jaybaird]

Potential fix for #9. I recevied an email from someone using Apple Mail that attached an inline PDF. Vireo did not display or detect that there was an attachment in the message. This checks the message for an inline base64 attachment and triggers the attachment download and attachment viewer for these messages.

Displaying inline I think is a non-starter due to https://bugs.webkit.org/show_bug.cgi?id=164423.

[hyprlab]

Thank you for this — the bug you found is fixed as of v1.10.1, and your report is what drove it. I'm closing this pull request because the fix that shipped works differently, and it's worth explaining why rather than leaving it to guesswork.

Your diagnosis was right, and the extraction half turned out to be already fixed. I ran the test from this branch verbatim against main and it passes unmodified — 1.7.2 reworked extract_attachments and structure_has_attachment, and since then mail_parser surfaces an inline, non-CID binary leaf through attachments() for both the nested alternative → mixed shape in your test and the top-level mixed shape from #9. So the collect() walk is no longer needed.

The real gap was that nothing ever asked. The paperclip is decided before any body is fetched, and attachments are only downloaded for messages that decision flagged — so a message it missed could never correct itself: no flag, no fetch, no attachments, indefinitely. That's what made the file invisible even though the parser could see it.

On the summary_from_headers change — treating a top-level multipart/alternative as attachment-bearing does catch the nested shape, but it would put a paperclip on nearly every HTML newsletter for accounts on that code path (iCloud, whose structured responses Vireo's IMAP parser rejects), correcting itself only after each message is opened. That's the false-paperclip noise removed in 1.4.1, so I didn't want to trade it back.

What shipped instead is evidence rather than a better guess. load_body already holds the whole message for the body and the sender check, so it now also reports whether attachments are genuinely present and the worker emits HasAttachments — the mirror of an existing NoAttachments event that has been clearing false paperclips the same way all along. The corrected flag is written to the cache so it survives a restart, the open message's files are fetched (the reader only asks when the flag was already set), and background prefetch runs the same check so recent mail is right before you open it. Nothing extra is fetched.

Both MIME shapes — yours and the reporter's — are now regression tests, and #9 is closed. Thanks for taking the time to dig into mail_parser and send a patch; it made this much quicker to place.

[hyprlab]

Fixed a different way in v1.10.1 (see above) — closing. Thanks again for the report and the patch.