docs(design): incremental async migration plan

[oferchen]

Summary

Adds docs/design/async-migration-plan.md (#1594) - a single roadmap that sequences the existing async sub-system designs into a five-phase, feature-gated migration with wire-compat preserved at every phase.

Five-phase outline

• Phase 1 - boundary-only async (today). Tokio runs only on the daemon accept edge and the embedded SSH transport. Hot transfer code is sync. Sync/async bridge via the TransferChannel trait and flume.
• Phase 2 - daemon listener flip (Ensure cross-compilation targets are installed in CI #1674). Async accept + sync workers, gated by --features async-daemon, env-var rollback OC_RSYNC_DAEMON_ASYNC=0.
• Phase 3 - SSH transport async (Handle daemon refusal banners before module list #1890). Async on Linux behind --features async-ssh, sync facade preserved elsewhere, env-var rollback OC_RSYNC_SSH_ASYNC=0.
• Phase 4 - receiver pipeline async (Decode percent-encoded RSYNC_PROXY credentials #1079, Modularize negotiation tests and fix client doc links #1591). Delta-apply on tokio runtime; ReorderBuffer reconsidered; explicit CancellationToken propagation; env-var rollback OC_RSYNC_RECEIVER_ASYNC=0.
• Phase 5 - rayon retreat (Add coverage for bandwidth limiter debt accumulation #1283). Rayon stays for pure-CPU compute, I/O is pure tokio, bridges via spawn_blocking / block_in_place with bounded pools; master kill switch OC_RSYNC_ASYNC=0.

Wire-compat invariant

Zero protocol changes across all phases. No new MSG_ frame types, no new capability flags, no new @RSYNCD: greeting variants, no new exit codes. Each phase rollout PR ships a tcpdump replay that must be byte-identical to upstream rsync 3.4.1. The async migration is purely an internal concurrency model change.

Phases 4 and 5 are explicitly "if benchmarks justify"; the project may stop indefinitely at the end of any phase.

Test plan

• Doc renders cleanly on GitHub.
• No cargo impact (docs-only change).
• CI passes the docs lint job.