Summary

gws gmail +send --html currently produces a single-part text/html message, while gws gmail +reply-all --html produces multipart/alternative (HTML + a plain-text alternative). Behavior parity across the helpers would be useful.

Current behavior

$ gws gmail +send --to me@example.com --subject test --html --body '<p>hi</p>'
$ gws gmail users messages get --params '{"userId":"me","id":"<id>","format":"metadata"}' \
 | jq .payload.mimeType
"text/html"

$ gws gmail +reply-all --message-id <msg> --html --body '<p>hi</p>'
$ gws gmail users messages get --params '{"userId":"me","id":"<id>","format":"metadata"}' \
 | jq .payload.mimeType
"multipart/alternative"

Desired behavior

+send --html (and +forward --html if applicable) emits multipart/alternative with two parts:

1. text/plain: strip-tags fallback of the HTML body
2. text/html: the user-supplied HTML body

Why it matters

1. Some corporate spam gateways slightly down-weight text/html-only mail vs. multipart.
2. Text-only clients and accessibility tools have no fallback content.
3. Helper-to-helper consistency: +reply-all already does this; +send should too.

Implementation note

The compiled binary already references multipart/alternative, and +reply-all's codepath produces it, so the MIME composer supports it. Looks like a small wiring change in the +send helper to plumb the alternative-part construction.

Version

gws 0.22.5 (macOS x86_64).