Fix IMAP connection exhaustion under burst of searches

[rockfordlhotka]

Problem

A burst of repeated search_emails calls (e.g. 5 searches in ~90s) hangs for the full request timeout against Gmail. Each IMAP read/mutation operation opened a brand-new connection, ran a fresh AUTHENTICATE, then closed it via Dispose() without a graceful LOGOUT. Abruptly-dropped connections linger server-side against Gmail's per-account simultaneous-connection limit, and Gmail throttles repeated AUTHENTICATE. The burst exhausts the limit/trips the throttle and stalls the next AUTHENTICATE, so subsequent calls hang. send_email was unaffected because its SMTP path (and IMAP append) already disconnected gracefully.

Fix

ImapProviderService now keeps and reuses a single authenticated IMAP connection per account:

• Per-account SemaphoreSlim gate serializes access (an ImapClient runs one command at a time).
• NOOP health-check before reuse; transparent reconnect if dead, plus a single reconnect-and-retry if a reused connection breaks mid-operation.
• Graceful DisconnectAsync(true) (LOGOUT) on eviction and on shutdown via new IAsyncDisposable/IDisposable.
• All read/mutation ops + the APPEND-to-Sent step of send_email route through the pool.

This removes the throttled repeated AUTHENTICATE round-trips and prevents connection-slot exhaustion.

Notes

• Pooling serializes IMAP calls per account — desirable here to stay within Gmail's connection limits; concurrent same-account requests queue rather than open parallel connections.
• Version bumped 1.4.0 → 1.4.1 (patch, bug fix). Changelog added.

Testing

• dotnet build clean (only pre-existing warnings).
• All 275 tests pass.