fix: batch and compress UID FETCH for large mailboxes

[furriest]

Problem

Mailboxes with a few thousand messages (~2500 in the reported case, against Kerio Connect) appeared empty in JMAP clients while Mailbox/get correctly reported the total message count.

Root cause

fetchSortMetadata() and the hasAttachment post-filter each build a UID FETCH command by joining every matching UID with commas:

const range = uids.join(",");

For a mailbox with thousands of messages this produces a command line long enough to exceed the line-length limits some IMAP servers enforce more strictly than Dovecot/Gmail (observed with MDaemon). The FETCH fails or the connection drops, and the resulting error isn't surfaced as a JMAP-level error — the client just sees an empty result set.

Fix

• Sort UIDs and chunk them into batches (200 per FETCH).
• Compress each batch into IMAP sequence-set ranges (compressUidsToRanges), e.g. [100,101,102,110] → "100:102,110", instead of a flat comma-separated list.
• Applied to both fetchSortMetadata (the Email/query sort/fetch path) and the hasAttachment post-filter, which had the same pattern.

Testing

• npx tsc -p tsconfig.json passes clean.
• Verified against a live MDaemon mailbox with ~2500 messages: previously returned an empty Email/query result, now returns correctly paginated results.

Happy to add a regression test against the integration compose stack if useful — wasn't sure whether you'd rather fake a large mailbox in compose.test.yml or mock at the ImapFlow level.