bug(gmail): +read silently loses body content — prefers empty text/plain part, truncates, drops anchor hrefs #889

gws gmail +read returns incomplete message bodies with no indication that content was dropped. Three distinct failures, all silent:

1. Prefers a stub text/plain part over a rich text/html part. On a real multipart/alternative message, the text part was 59 chars with zero URLs; the HTML part was 17,590 chars containing 6 links. +read returned the 59-char stub, discarding the entire message.

2. Truncates. A 3,209-byte draft came back as 198 bytes, cut mid-word. No [truncated] marker.

3. Drops anchor targets. HTML→text conversion discards href values, so any message whose payload is a link — invitations, password resets, portal access, OTP magic links — is unreadable. One invitation rendered as invisible word-joiner characters with no URL at all.

Also: HTML entities aren't unescaped (' appears literally) and block elements don't produce line breaks, so multi-paragraph bodies collapse to one line.

Impact: consumers can't tell content was lost. Worse for drafts — a correct outbound draft looks mangled, and the natural response is to delete and rebuild it.

Suggested: emit the full decoded body, select the richer alternative part when text/plain is empty or substantially shorter, preserve href targets (inline or as a link list), unescape entities, and if any cap is retained, print an explicit [truncated N bytes] marker.

Version: 0.22.5