fix(imap): use destination UIDVALIDITY in APPENDUID / COPYUID response codes

[ssilvius]

Summary

Fixes issue #83 (hardcoded `APPENDUID 1`) plus two related bugs of the same shape in COPY and MOVE that I found while re-auditing the extension handlers. Breaking change to the `ExtensionAdapter` interface -- the three return types now carry `uidValidity`.

The bugs

RFC 4315 Section 3 says APPENDUID and COPYUID carry the destination mailbox's UIDVALIDITY as their first argument. RFC 6851 Section 4 inherits the same semantics for MOVE. Three handlers got this wrong:

1. `handleAppend` hardcoded `APPENDUID 1 ${uid}`. Literal `1` regardless of actual destination UIDVALIDITY.
2. `handleCopy` used `uidMap.uidValidity` which is the source folder's validity, not the destination's.
3. `handleMove` had the same source-vs-destination bug as COPY.

Any IMAP client that caches by `(uidValidity, uid)` tuples (which is standard) would either trust stale data or invalidate unnecessarily on every COPY/MOVE/APPEND.

The fix

Extended the `ExtensionAdapter` interface to return `uidValidity` from all three methods. The adapter knows the destination's UIDVALIDITY because it just wrote to that folder -- no extra query needed:

```typescript
interface ExtensionAdapter {
copyMessage(messageId, targetFolderId): Promise<{ newUid, uidValidity }>;
moveMessage(messageId, targetFolderId): Promise<{ newUid, uidValidity }>;
appendMessage(folderId, content, flags, date?): Promise<{ uid, uidValidity, messageId }>;
// ...
}
```

Handlers updated to use the returned validity:

• `handleAppend`: `[APPENDUID ${result.uidValidity} ${result.uid}]`
• `handleCopy` / `handleMove`: capture `destUidValidity` on first adapter call (all copied/moved messages share one destination, so it's constant across the loop) and use it in the `COPYUID` response.

Also added a "no messages copied/moved" guard: if the sequence set resolves to zero messages, the handler now omits the `COPYUID` response code entirely and returns tagged OK. Previously the code emitted `[COPYUID ]` with trailing empty strings.

Breaking change

`ExtensionAdapter` is a public interface consumers implement. The return-type extension is a breaking change -- existing adapter implementations that return `{ newUid }` without `uidValidity` will fail typecheck on upgrade. The upgrade is mechanical: add `uidValidity` to each method's return. Pre-1.0 is the right time; no consumers have written adapters yet against the published packages.

Tests

Three new tests in `packages/imap/tests/commands/extensions.test.ts`, each citing the RFC section it verifies:

1. `returns destination UIDVALIDITY in APPENDUID response (RFC 4315 Section 3)` -- mock adapter returns `uidValidity: 42, uid: 300`. Asserts response contains `[APPENDUID 42 300]`. Before the fix: `[APPENDUID 1 300]`.
2. `returns destination UIDVALIDITY in COPYUID response (RFC 4315 Section 3)` -- source session has `uidValidity: 1`, mock returns `uidValidity: 42`. Asserts response contains `[COPYUID 42`. Before the fix: `[COPYUID 1 ...]`.
3. `returns destination UIDVALIDITY in MOVE's COPYUID response (RFC 6851 Section 4)` -- same pattern for MOVE.

The existing `toContain("APPENDUID")` / `toContain("COPYUID")` substring-match tests stayed -- they still pass because the prefix appears in both old and new responses. The new tests check the actual validity value, which the old tests never did.

Process note

I wrote the failing tests first, confirmed they reproduced the bugs, then fixed the implementation. This is the corollary I added to memory after yesterday's audit mistake with issue #82 (which I filed based on an incomplete parser read). Writing the failing test first would have caught that mistake too -- there was no way to write a failing test because the feature existed.

Verification

• `pnpm --filter @rafters/mail-imap test`: 316 passing (313 existing + 3 new)
• `pnpm test` (workspace): 617 passing across 37 files (was 614 + 3 new)
• `pnpm -r build`: all 9 packages ESM + dts clean
• `pnpm typecheck`: clean
• `pnpm lint`: 0 warnings, 0 errors
• `pnpm format:check`: clean
• `legion-simplify` gate: clean

Closes #83.