fix: defer metadata application until after disk thread commit

[oferchen]

Summary

• Fix race condition in decoupled receiver where metadata (mtime, permissions, ownership) was applied before the disk thread had committed the file to its final path
• This caused mtime not to be preserved in daemon mode, making the quick-check algorithm ineffective for incremental syncs

Root Cause

The decoupled receiver architecture (introduced in PR #2338) separated network I/O from disk I/O via a bounded channel + disk commit thread. However, metadata was applied on the network thread immediately after queueing the commit, before the disk thread had flushed and renamed the temp file.

Sequence (buggy):

1. Network thread sends Commit message to disk thread
2. Network thread applies metadata to final path ← file doesn't exist yet!
3. Disk thread flushes, renames temp → final path

Fix

Defer metadata application to after drain_all_results() confirms all files are committed. Mirrors upstream finish_transfer() → set_file_attrs() which runs after do_rename(fnametmp, fname) in receiver.c.

Benchmark (10K files, 422MB, daemon mode)

Mode	Before Fix	After Fix	upstream rsync
Initial copy	578ms	627ms	1,034ms
Incremental (no changes)	923ms	121ms	137ms

• Incremental: 7.6x improvement (923ms → 121ms), now 1.13x faster than upstream
• Initial copy: no significant change
• Syscalls (incremental): 10,241 total — matches upstream's 10,414

Test plan

• All 21,724 tests pass
• Clippy clean, fmt clean
• Verified mtime preservation in daemon mode (stat comparison)
• Benchmarked initial copy — no regression
• Benchmarked incremental sync — 7.6x improvement
• Syscall profile matches upstream