Inbound email attachments / screenshots not landing on the created ticket

[akash2017sky]

Problem

Customers can attach files to a support email (screenshots, logs, PDFs) but they don't appear on the resulting Azure DevOps work item. Without the attachments, agents can't see what the customer is reporting and have to ask them to re-send.

Suspected Causes

The poll path (`src/lib/email-poll.ts`) calls `fetchAttachments` only when `hasAttachments=true` and then filters aggressively. Three failure modes are likely:

1. Inline images filtered out — `fetchAttachments` skips `isInline: true`. Pasted screenshots are almost always flagged inline by Outlook / Gmail, even when the user thinks of them as "attachments". Result: pasted screenshots silently disappear.
2. Reference attachments unhandled — Outlook auto-converts files >35 MB to OneDrive links (`#microsoft.graph.referenceAttachment`), and even smaller files when "Modern Attachments" is enabled in the tenant. These have no `contentBytes`, just a URL — currently skipped entirely.
3. Item attachments unhandled — forwarded `.eml` messages come through as `#microsoft.graph.itemAttachment` with no `contentBytes` either. Skipped.

When inline images are skipped, the only signal in the ticket is a stripped `<img src="cid:...">` reference in `uniqueBody` that the customer's client knew how to resolve but DevOps doesn't.

Expected

Every file the customer attached — inline or not — should land on the work item as a DevOps attachment. Reference attachments should at minimum produce a link in the ticket so the agent can click through to OneDrive / SharePoint.

Acceptance Criteria

• Inline images (cid: references) attached to inbound mail land on the DevOps work item as attachments
• The `<img src="cid:...">` reference in the body is rewritten to point at the uploaded DevOps attachment so the image still renders inside the ticket description / comment
• Reference attachments (OneDrive / SharePoint links) are surfaced in the ticket — either uploaded if the app can fetch them, or recorded as a clickable link in the description
• Item attachments (forwarded .eml) at least produce a tagged note ("Forwarded message: (not extracted)") so they don't vanish silently
• Attachment failure of any kind is logged with the work item ID + filename, but never blocks ticket creation
• On a thread reply (comment-add), the same attachment handling runs — currently it only runs for new tickets

Reproduction

1. Send an email to the support mailbox with a pasted screenshot in the body and an explicitly attached PDF
2. Wait for the poll to run
3. Open the resulting ticket in DevOps → expect both the screenshot and the PDF in the Attachments tab; today the screenshot is missing and the PDF works

Implementation Notes

• The simple inline fix is to drop the `isInline` filter in `fetchAttachments` (line in `email-poll.ts`). That alone covers the screenshot case but leaves `cid:` rewriting unsolved.
• For `cid:` rewriting: after upload, replace each `<img src="cid:CONTENT_ID">` in the body HTML with `<img src="">`. Requires switching the body fetch back to `uniqueBody` HTML (text dropped `` tags entirely) — and re-applying signature stripping on HTML, which is harder than on text.
• Reference attachments need `@microsoft.graph.downloadUrl` (sometimes present) or a Graph drive call to fetch the underlying file.

Out of Scope

• Encrypted / S/MIME attachments — separate decryption story
• Per-tenant attachment size limits — DevOps caps at 60 MB per file already

Related

• [FEAT] Email Channel Integration #55 (parent — Email Channel Integration)
• Email replies to customer should include full ticket history #359, Notify agents when a customer replies on an email-tagged ticket #360, Brand outbound emails with ZapDesk UI styling + ZapDesk and KnowAll AI logos #361 (siblings)