Feature request: Allow HTTP API clients to request HTML body

[rahimnathwani]

GET /api/v1/messages/{id} returns a single body field. When a message contains both text/plain and text/html parts, the API always returns the plain-text version, and the HTML is unreachable from any endpoint.

I'm building a web client against this API so I can have a "Gmail-like" experience over my archive, and rendering plain text loses links, lists, tables, inline images, and quoted-reply formatting on most modern mail. The TUI isn't affected because it reads the SQLite store directly.

Where

internal/store/api.go, in Store.GetMessage:

if bodyText.Valid {
    m.Body = bodyText.String
} else if bodyHTML.Valid {
    m.Body = bodyHTML.String
}

Plain text wins unconditionally. There's no query param to override, and POST /api/v1/query reads the Parquet analytics cache, which intentionally excludes message bodies — so the HTML is effectively unreachable.

Repro

curl -H "X-API-Key: …" http://localhost:5789/api/v1/messages/<id>

for any multipart/alternative message. The body field is plain text; the body_html row in message_bodies is populated but never surfaced.

Would you consider a PR which adds a body_html field to the response?

type MessageDetail struct {
    MessageSummary
    Body        string           `json:"body"`                // unchanged: text-preferred
    BodyHTML    string           `json:"body_html,omitempty"` // new: raw HTML when present
    Attachments []AttachmentInfo `json:"attachments"`
}

In GetMessage, populate both when available. Existing body semantics stay the same, so old clients are unaffected; new clients pick whichever representation they want.

Happy to put together a PR with a test in handlers_test.go covering a multipart/alternative message — just want to check it's a direction you'd accept before writing it.