imap: wire COPYUID capture once async-imap exposes ResponseCode::CopyUid

[randomparity]

Context

PR #106 landed sub-group 2 of the open-issues roadmap (#70, #96, #97). The #96 work is partial: `Connection::move_messages` guards UIDVALIDITY correctly but cannot populate `MoveResult.new_uid` because `async-imap` does not expose the `[COPYUID uidvalidity src-uids dst-uids]` UIDPLUS response code.

What exists today (on `main` after #106 merges)

• `rimap_imap::types::MoveResult { old_uid: Uid, new_uid: Option, used_fallback_reason: Option }`.
• Every `MoveResult` returned by `move_messages` currently has `new_uid: None` and `used_fallback_reason: Some("async_imap_copyuid_unavailable".to_string())` — a stable marker the audit layer / agent can filter on.
• `MoveOutcome { results, used_fallback, source_uid_validity, destination_uid_validity }` already surfaces both folder UIDVALIDITY values for audit correlation, so the loss of per-result `new_uid` is bounded.
• `ResponseCode::CopyUid(u32 /* uidvalidity /, Vec / src /, Vec / dst */)` exists in `imap-proto 0.16.6` (`types.rs:139`) but `async-imap 0.11.2`'s session methods (`uid_copy`, `uid_mv`) return `Result<()>` and discard response codes.

What this issue tracks

Once `async-imap` exposes the UIDPLUS response code — either via a new session method signature (e.g. `Result`) or via raw-command machinery that cleanly surfaces `Response::Done { code: Option, ... }` — flip `build_results` in `crates/rimap-imap/src/ops/move_message.rs` to:

1. Parse the `[COPYUID ...]` response code when available.
2. Populate `MoveResult.new_uid: Some(Uid::new(dst_uid))` for each matched source UID.
3. Set `used_fallback_reason: None` on results with populated `new_uid`.
4. Keep the current fallback (`new_uid: None` + `used_fallback_reason: Some("server_no_uidplus")` or similar) for servers that do not advertise UIDPLUS.

Acceptance criteria

1. When the server advertises UIDPLUS (`has_uidplus`) AND async-imap surfaces the response code, `MoveResult.new_uid` is populated with the mapped destination UID for every moved message. Verified via a Dovecot integration test that checks `new_uid` is `Some(...)` on a simple 3-message MOVE.

2. When the server does NOT advertise UIDPLUS, `new_uid` stays `None` with `used_fallback_reason: Some("server_no_uidplus".to_string())` (or equivalent).

3. `Connection::move_messages` signature is unchanged — flip is a behavior change, not an API change.

4. `MoveMessageMeta` (in `rimap-server/src/tools/mailbox/move_message.rs`) surfaces the captured `new_uid` values in the per-result entries automatically; no server-side code change needed beyond what feat: UIDVALIDITY correctness — Option<u32>, MOVE guard, response echo, input check #106 already landed.

Blockers / watch

• Upstream: track `async-imap` releases for UIDPLUS response-code support.
• Fallback: if async-imap doesn't land the feature in a reasonable timeframe, consider using async-imap's internal `run_command_and_read_response` (or equivalent) to issue `UID COPY` / `UID MOVE` as raw commands and parse the tagged response manually. That's more invasive but removes the external dependency.

References

• PR feat: UIDVALIDITY correctness — Option<u32>, MOVE guard, response echo, input check #106 — the scaffold commits `248f1bb` (MOVE guard + `used_fallback_reason`) and `d294c28` (response echo) / `9f7e2cb` (input guard).
• Plan: `docs/superpowers/plans/2026-04-19-uidvalidity-correctness.md` §Task 2 + Task 5.
• RFC 4315 — IMAP UIDPLUS Extension (§3, COPYUID response code).
• imap-proto 0.16.6 — `ResponseCode::CopyUid` definition.

🤖 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/ops/move_message.rs:206-216 — build_results() still unconditionally returns:

  MoveResult { old_uid: uid, new_uid: None, used_fallback_reason: Some("async_imap_copyuid_unavailable".to_string()) }

  Called from both the uid_mv path (line 126) and the COPY+DELETE fallback (line 200). The fallback marker remains a stable string the audit layer / agent can filter on.
• crates/rimap-imap/src/types.rs:177-191 — MoveResult { old_uid, new_uid: Option<Uid>, used_fallback_reason: Option<String> }.
• crates/rimap-imap/src/ops/move_message.rs:18-32 — MoveOutcome { results, used_fallback, source_uid_validity, destination_uid_validity }.
• crates/rimap-server/src/tools/mailbox/move_message.rs:45-73,113-120 — MoveMessageMeta already plumbs new_uid through to MCP clients; flipping build_results requires no server-side change.

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 this surface.
• Session signatures still discard response codes:

  pub async fn uid_copy<S1, S2>(&mut self, uid_set: S1, mailbox_name: S2) -> Result<()>
  pub async fn uid_mv<S1, S2>(&mut self, uid_set: S1, mailbox_name: S2) -> Result<()>
  pub async fn copy<S1, S2>(&mut self, sequence_set: S1, mailbox_name: S2) -> Result<()>
  pub async fn mv<S1, S2>(&mut self, sequence_set: S1, mailbox_name: S2) -> Result<()>
  pub async fn append(&mut self, ..., content: impl AsRef<[u8]>) -> Result<()>

• src/parse.rs matches only UidValidity, UidNext, HighestModSeq, Unseen, PermanentFlags on ResponseCode — CopyUid/AppendUid are silently discarded. No Response::Done { code } surface from any session method.
• CHANGELOG for 0.10.x/0.11.x mentions nothing about COPYUID / UIDPLUS / APPENDUID / ResponseCode.
• Upstream tracking issue Implement UIDplus extension chatmail/async-imap#11 ("Implement UIDplus extension") — still open, no activity since 2023-08-28.

imap-proto

• ResponseCode::CopyUid(u32, Vec<UidSetMember>, Vec<UidSetMember>) is still present at imap-proto-0.16.6/types.rs:139 (our lockfile version). The dependency is ready; only async-imap's plumbing is missing.

Conclusion

Still blocked on async-imap. Re-check on the next 0.11.x / 0.12 release, or if chatmail/async-imap#11 shows movement. The fallback (issue UID COPY / UID MOVE via lower-level command machinery and parse the tagged response manually) remains documented in the original issue but is out of scope for now.