Fix: edit_draft no longer corrupts the other body on a partial edit

[JonathanGodley]

The bug

updateDraft rebuilds a draft's body to re-send it (JMAP bodies are immutable, so an edit is a destroy + recreate). It reads the existing bodies back from the fetched email:

const existingTextBody = ...Object.values(bodyValues).find((bv) =>
  existingEmail.textBody?.some((tb) => tb.partId === bv.partId || true));

The || true makes the predicate unconditionally true — and the bodyValue objects from Object.values() have no partId field anyway (partId is the map key). So both existingTextBody and existingHtmlBody resolve to Object.values(bodyValues)[0], the first part.

Consequences on an edit that doesn't explicitly set a given body:

• Dual-format draft, edit only the subject (or only one body): the other body is overwritten with the first part's value. e.g. a subject-only edit replaces the HTML body with the plain-text value; since clients render the HTML alternative (RFC 2046 §5.1.4), the recipient sees the wrong content.
• Single-format draft: the server aliases the one part into both the textBody and htmlBody lists (a text-only draft's htmlBody entry has type: "text/plain"), so the lookup pulls that value into the missing format and a phantom part is synthesised on recreate.

The fix

Select each existing body value by MIME type, keyed into bodyValues by the matched part's partId:

const bodyValues = existingEmail.bodyValues || {};
const bodyValueForType = (parts, mimeType) => {
  const part = parts?.find((p) => p.type === mimeType && p.partId != null && bodyValues[p.partId]);
  return part ? bodyValues[part.partId].value : undefined;
};
const existingTextValue = bodyValueForType(existingEmail.textBody, 'text/plain');
const existingHtmlValue = bodyValueForType(existingEmail.htmlBody, 'text/html');

Matching by MIME type (rather than only keying by partId) is what handles the single-format aliasing: a text-only draft's htmlBody entry is text/plain, so it correctly yields no HTML value and no phantom part. type is already requested in the Email/get bodyProperties, so there is no request change.

Verified against a live Fastmail account (text-only, html-only, and dual-part drafts):

• subject-only edit on a dual draft → both bodies preserved
• textBody-only edit → text updated, HTML partner preserved
• text-only draft edit → no phantom html part

Tests

Adds 3 unit tests to the updateDraft suite covering the aliased single-format and dual-format shapes, asserting on the recreate output. Each fails before the fix and passes after.

(The 2 pre-existing safeWritePath symlink tests fail locally on Windows — EPERM, symlink creation needs elevation — but are untouched by this change and pass on CI.)