feat: add persistent inline images to email signatures

[halcycon]

Summary

Adds persistent image assets to HTML email signatures.

Signature images are stored separately from JMAP Identity.htmlSignature, avoiding server signature-size limits (notably on Stalwart). When composing, Bulwark loads the stored signature image and reuses the existing inline-image upload pipeline. At send time the HTML is rewritten to use cid: and the image is included as a Content-Disposition: inline JMAP/MIME attachment.

This avoids remote image hosting and allows signature images to display without requiring recipients to enable remote content.

Existing text and HTML signatures continue to use JMAP Identity fields and remain backwards compatible.

Implementation notes

• Storage: Encrypted signature asset store (SIGNATURE_DATA_DIR, default data/signatures), keyed by account hash + identity hash + asset UUID.
• Settings sync: Extended signature HTML (data-signature-asset references) lives in synced extendedSignatures; binaries stay in the asset store.
• Send path: Reuses existing composer uploadBlob / data-cid / rewriteInlineImages — no second MIME implementation.
• JMAP fallback: Image-free HTML fallback is written to Identity.htmlSignature for other clients.

Test plan

• Save identity, edit identity, insert JPEG/PNG signature image; preview shows image after reload
• Compose new message — signature image visible in composer
• Send message — outgoing HTML uses cid:, inline attachment present, no public image URL
• Reply / forward with signature above and below quoted text
• Switch identity in composer — signature image swaps without affecting manually inserted body images
• Autosaved draft retains signature image; reopen and send
• Plain-text and image-free signatures unchanged
• Docker: mount bulwark-signatures volume; images survive container restart

Automated tests

• npx vitest run lib/__tests__/signature-assets.test.ts lib/__tests__/extended-signatures.test.ts
• npm run typecheck && npm run lint

Made with Cursor