fix(sftp): 目录上传改为受限并发，消除小文件串行往返（#265）

[feigeCode]

Refs #265

Description

Directory uploads were fully serial: upload_dir_with_progress uploaded one file at a time. Combined with the fixed per-file control round trips that with_remote_replace requires (stat / open / fsync / fstat / close / rename), small-file throughput was bound by RTT instead of bandwidth — roughly 180 ms per file at 30 ms RTT, i.e. over 3 minutes for 1000 small files.

Changes

• New module crates/sftp/src/upload_batch.rs:
  • run_bounded — bounded concurrency built on futures::stream::FuturesUnordered. Deliberately not JoinSet: JoinSet::spawn requires 'static futures, but with_remote_replace borrows &SftpSession from the caller's stack, so the borrow cannot be erased.
  • ConcurrencyBudget — slot-based budget. A small file takes one slot; a file larger than SMALL_FILE_MAX_BYTES takes the whole budget.
  • ProgressHighWater — monotonic high-water mark so interleaved per-file callbacks cannot pull the progress bar backwards.
• upload_dir_with_progress now runs file uploads through run_bounded with a concurrency of 6. Files above SMALL_FILE_MAX_BYTES (512 KiB, aligned with the existing PIPELINE_THRESHOLD) still take the entire budget, so large-file behaviour is unchanged: the write path already saturates the 64 × 256 KiB pipeline window, and overlapping large files would only increase unacknowledged bytes in memory without gaining throughput.
• Progress transferred is now accumulated in a global AtomicU64 instead of "completed files + current file".
• Failure semantics are preserved on purpose: after the first error no new job is admitted, but in-flight jobs run to completion before the error is returned. Dropping them early would leave RemoteReplaceTemp staging files (.name.navop-part-<uuid>) on the remote, because cleanup() would never run.

AI assistance: the code in this PR was generated with AI assistance. It was reviewed, formatted with rustfmt and tested locally. It follows the module organisation and naming conventions already used in crates/sftp/src/.

Screenshot

No UI change — this is a transfer performance fix.

How to Test

• Red → Green: 8 new unit tests in upload_batch.rs; 5 of them fail before the implementation (job weighting, concurrency peak, non-monotonic progress, no drain-on-error).
• cargo test -p sftp → 93 passed, 0 failed.
• cargo clippy -p sftp --all-targets → no new warnings.
• rustfmt --check clean on the touched files.
• cargo check -p sftp_transfer -p sftp_view -p remote_file_editor -p ftp → passes.

Reproducing the original scenario (optional): run a local SFTP server behind a TCP latency proxy, then upload 100 × 5 KB files. Sequentially over a 40 ms proxy this takes about 18.5 s; the concurrent path is expected to land in the 3–4 s range.

Note: this PR does not include an end-to-end throughput number over a real WAN link. The unit tests pin the scheduling semantics (real overlap, large files stay serial, in-flight jobs drain on error, monotonic progress), not real network speed.

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate.
• Passed cargo run for story tests related to the changes. — N/A, this change touches no UI or component code.
• Tested macOS, Windows and Linux platforms performance (if the change is platform-specific) — build and tests verified on macOS only.