perf: isolate migration disk I/O from live server workload

[WieszczY85]

Problem

Migration commands already delegate provider work to the dedicated migration executor, but the universal fallback scan can still stream up to the configured aggregate limit (1 GiB by default). Running that work on another thread prevents direct tick-thread blocking, but unrestricted reads can still saturate the same storage used by world saves and plugin databases, which presents as visible server lag.

The universal provider also rebuilt its filesystem plan during migrate() immediately after the coordinator had already completed the mandatory inspection, causing another deep scan in the same migration pipeline.

Changes

• pace universal migration filesystem reads/writes in 64 KiB chunks with an 8 MiB/s background I/O budget;
• reuse the plan produced by the immediately preceding mandatory inspection inside the same provider/pipeline, avoiding a duplicate deep content scan;
• keep the plan cache bounded and short-lived, keyed to migration/source/target identity and remove it after migration/rollback;
• keep the existing single-threaded bounded migration executor, total-byte/file-count limits, symlink checks, backup and rollback behavior;
• add regression coverage confirming inspection completion happens on the dedicated migration worker rather than the caller thread;
• document the execution model and why an async worker still needs disk-I/O pacing.

Bukkit/Paper state checks and UI dispatch intentionally remain on the proper server/entity scheduler. The expensive file scanning/copying continues on authgatewayx-migration; this change additionally prevents that background worker from monopolizing disk bandwidth.

The intended trade-off is lower impact on a live server at the cost of longer migration/inspection time for very large unmanaged plugin datasets.