imap: wire LIST-STATUS (RFC 5819) extended LIST once async-imap exposes it

[randomparity]

Context

PR #104 landed sub-group 1 of the folder-listing hardening sweep (#91, #92, #95, #98). The #92 work is partial: the LIST-STATUS capability flag and the public shape of Connection::list_folders_with_status are plumbed, but the actual single-round-trip wiring is deferred because `async-imap` does not yet expose the extended LIST command.

What exists today (on `main`)

• `rimap_imap::connection::Connection::has_list_status_capability() -> bool` — probed post-login alongside `MOVE` / `UIDPLUS` via `caps.has_str("LIST-STATUS")`.
• `rimap_imap::connection::Connection::list_folders_with_status(pattern: &str) -> Result<Vec<(Folder, Option)>, ImapError>` — public async method. Always takes the per-folder-STATUS fallback path regardless of the capability.
• `rimap_imap::ops::folders::list_with_status(session, pattern, _has_list_status: bool)` — the inner helper. The `_has_list_status` argument is reserved for the dispatch flip.
• `rimap_server::tools::admin::list_folders::handle` already calls `list_folders_with_status` and will pick up the optimization automatically.

What this issue tracks

Once `async-imap` exposes LIST-STATUS — either through a dedicated `Session::list_status` method or through generic raw-command machinery that cleanly parses interleaved `STATUS` response-data lines alongside `LIST` — flip the dispatch in `list_with_status` to issue `LIST "" RETURN (STATUS (MESSAGES UIDVALIDITY UNSEEN))` as a single round-trip when `has_list_status` is true.

Acceptance criteria

1. When the server advertises `LIST-STATUS` and async-imap's API supports the extended LIST, `list_folders_with_status` issues ONE IMAP command and returns `Vec<(Folder, Option)>` with STATUS pre-populated — verified by counting round-trips in a Dovecot integration test (Dovecot 2.3+ supports LIST-STATUS).

2. When async-imap's API is available but the server does NOT advertise `LIST-STATUS`, the fallback path is taken unchanged. No regression on legacy servers.

3. Non-selectable folders continue to return `status = None` regardless of path.

4. Signature of `Connection::list_folders_with_status` and `rimap_server::tools::admin::list_folders::handle` is unchanged — the flip is a behavior change, not an API change.

Blockers / watch

• Upstream: track `async-imap` releases for LIST-STATUS support. If it doesn't land in a reasonable timeframe, the alternative is to use async-imap's `run_command_and_check_ok` (or equivalent) with an untagged-response channel, and parse the STATUS data lines manually. That's more invasive but removes the external dependency.

References

• PR feat: folder listing hardening — typed attrs, name validation, sanitize, LIST-STATUS scaffold #104 — the scaffold commits `5874a3b` (capability probe + op) and `b002cba` (tool handler wiring).
• Plan: `docs/superpowers/plans/2026-04-19-folder-listing-hardening.md` §Task 7.
• RFC 5819 — IMAP4 Extension for Returning STATUS Information in Extended LIST.

🤖 Generated with Claude Code

[randomparity]

Upstream status check — 2026-05-27

Re-verified against the codebase and upstream async-imap. No changes needed; leaving open as the upstream tracker.

Local scaffold (confirmed on main)

• crates/rimap-imap/src/connection/mod.rs:115 — has_list_status: AtomicBool field on ConnectionInner.
• crates/rimap-imap/src/connection/mod.rs:227-229 — pub fn has_list_status_capability(&self) -> bool.
• crates/rimap-imap/src/connection/login.rs:147-167 — capability is set from caps.has_str("LIST-STATUS") post-login, alongside MOVE/UIDPLUS.
• crates/rimap-imap/src/connection/dispatch.rs:76-85 — pub async fn list_folders_with_status(&self, pattern: &str) reads the atomic and forwards it.
• crates/rimap-imap/src/ops/folders.rs:110-137 — list_with_status(session, pattern, _has_list_status: bool); the _ prefix marks the dispatch flip as reserved, and the body unconditionally takes the per-folder STATUS fallback.
• crates/rimap-server/src/tools/admin/list_folders.rs:166 — tool handler already calls list_folders_with_status; will pick up the flip automatically.

async-imap upstream (verified 2026-05-27)

• Latest crates.io release: 0.11.2 (2026-02-10) — matches our pin.
• Upstream main (f0fa62b3) is at the 0.11.2 release commit; no unreleased work touches LIST.
• Repo chatmail/async-imap (the project moved from async-email/).
• src/extensions/ contains only compress.rs, id.rs, idle.rs, mod.rs, quota.rs — no list_status.rs / list_extended.rs.
• The only LIST API exposed is Session::list(reference_name, mailbox_pattern) -> Result<impl Stream<Item = Result<Name>>> — no RETURN parameter, no sibling method.
• CHANGELOG entries for 0.11.0/0.11.1/0.11.2 contain zero mentions of LIST-STATUS, RFC 5819, or extended LIST.
• No open PR targets LIST-STATUS. Issue Support for IMAP4rev2 (RFC 9051) and SMTPUTF8 (RFC 6531) chatmail/async-imap#126 (IMAP4rev2) is open and would include it but has no implementation work; IMAP response parsing issues chatmail/async-imap#131 only mentions the string verbatim inside a CAPABILITY parser bug report.

Conclusion

Still blocked on async-imap. Will re-check on the next 0.11.x or 0.12 release. The fallback (use lower-level run_command_and_check_ok plus manual parsing of interleaved untagged LIST + STATUS data lines) remains documented in the original issue but is out of scope for now.