BUG: inline cid: images never render — attachment parts cached without payload

[alejodelosrios]

Describe the bug

Inline images referenced as cid: are never rendered. Remote https:// images in the same message render correctly via the Kitty graphics protocol.

The root cause is not Content-ID matching — the IDs match exactly. Attachment entries are cached with metadata only and no payload bytes, so the CID lookup always resolves against an empty map.

From ~/.cache/matcha/email_bodies/INBOX.json, one message's attachment entry:

{
  "filename": "Outlook-fbf5u0c5.png",
  "part_id": "1.2",
  "encoding": "base64",
  "mime_type": "image/png",
  "content_id": "ed77b514-0bc5-49a8-957d-8c223b4618b5",
  "inline": true
}

There is no field holding the decoded part. The HTML body of the same message references cid:ed77b514-0bc5-49a8-957d-8c223b4618b5 — an exact match on content_id.

With DEBUG_KITTY_IMAGES=1:

[img-protocol] cid lookup for ed77b514-0bc5-49a8-957d-8c223b4618b5 found=false len=0
[img-protocol] no payload for src=cid:ed77b514-0bc5-49a8-957d-8c223b4618b5
[img-protocol] cid lookup for c84ee271-9399-40a4-a1b9-353f1e7b6ef3 found=false len=0
[img-protocol] no payload for src=cid:c84ee271-9399-40a4-a1b9-353f1e7b6ef3

Remote images in the very same render pass succeed:

[img-protocol] remote fetch ok url=https://... len=28064
[img-protocol] termimage: prerendered rows=2 bytes=5001
[img-protocol] collected image placement src=https://... rows=2

So the terminal, the protocol detection, and termimage all work. Only the cid: path is broken, and it looks like the inline part bodies are simply never fetched before render.

Opening the attachment from the attachments pane (which hands it to the OS previewer) does not populate the map either — re-toggling images afterwards still logs found=false.

To reproduce

1. Open an email containing inline images referenced by cid: (e.g. anything composed in Outlook, which inlines pasted images this way).
2. Press i to toggle images.
3. Remote images appear; inline cid: images do not.
4. Optionally run with DEBUG_KITTY_IMAGES=1 matcha 2>/tmp/img.log and observe no payload for src=cid:....

Expected behavior

Inline cid: images render like remote ones — the referenced MIME part is fetched and decoded so the CID lookup resolves.

Screenshots

n/a — the images are simply absent from the rendered body.

Matcha version

1.0.0-rc1 (133c051)

OS

macOS

OS version

macOS 26.5.1

Architecture

arm64 (aarch64 / Apple Silicon)

Additional context

• Terminal: Ghostty. Kitty graphics verified working independently of matcha.
• Provider: Proton Mail via Proton Mail Bridge (IMAP 127.0.0.1:1143, STARTTLS). Since Bridge rebuilds MIME on decrypt, that was the first suspect — but the cached content_id matches the HTML cid: reference exactly, which rules it out.
• disable_images is false.

Diagnosis was done with the help of an AI assistant; the log excerpts and cache dump above are verbatim from the affected machine.