Expose BODYSTRUCTURE octet count as MessagePart.size

[appinteractive]

What

BODYSTRUCTURE reports each body part's size in octets, but the value was dropped when building MessagePart from a parsed BodyStructure. This carries it through as a new optional property:

/// The size of the part body in octets, as reported by BODYSTRUCTURE (if any)
public let size: Int?

NIOIMAP parses a missing/zero field as 0, which is surfaced as nil.

Why

With part sizes available from the envelope/structure fetch alone, clients can show size labels and enforce download caps (e.g. skip auto-fetching a 40 MB scan for a thumbnail) without fetching any part bytes. We use this in a mail client that builds an attachment metadata index from BODYSTRUCTURE during sync.

Changes

• MessagePart: new size: Int? property, threaded through both public initializers and the Codable implementation (encoded with encodeIfPresent, so existing archives decode fine).
• MessagePart+BodyStructure: read fields.octetCount when flattening singleparts; > 0 becomes the size, otherwise nil.
• New MessagePartSizeTests: singlepart carries the octet count, zero yields nil, multipart children each carry their own size.

Note: the size is the encoded (transfer-encoding) octet count per RFC 3501 — for base64 parts roughly 4/3 of the decoded file size. Documented as "as reported by BODYSTRUCTURE" to keep that semantic.

[odrobnik]

Request changes: the new conversion drops a legitimate BODYSTRUCTURE octet count of zero. In the pinned NIOIMAP 0.3.0 parser, body-fld-octets is required and parsed as an unsigned number; a missing field makes the body structure invalid and never reaches this converter, while 0 is preserved as a valid reported size. The model should retain 0 so callers can distinguish a known-empty part from unavailable size metadata. The remaining construction, recursion, and Codable paths inspected are consistent. Builds and tests were not run, per review instructions.

Findings:

• MEDIUM Sources/SwiftMail/IMAP/Models/MessagePart+BodyStructure.swift:45 — When an IMAP server reports a valid empty MIME part with body-fld-octets equal to 0, this branch stores nil instead of the reported zero. A client using size to show exact metadata or to allow only known-within-cap downloads then treats the empty part as unknown-size and may hide its size or refuse to fetch it. NIOIMAP 0.3.0 does not use zero as a missing-field sentinel: the octet field is mandatory in its parser, and a missing value produces an invalid BODYSTRUCTURE that is ignored by SwiftMail's handlers.

[odrobnik]

Thanks @appinteractive for the contribution — exposing the BODYSTRUCTURE octet count is a great addition! 🙏

We took care of the review nitpick (a reported octet count of 0 was collapsed to nil; since body-fld-octets is mandatory in the parser, zero is a legitimate size of an empty part and is now preserved) in #187, which carries your commit as-is with main merged in. Once #187 lands, this PR will automatically show as merged.