Speed up macOS directory scans when bulk reads stall

[Byron]

Tasks

This section is for Byron only. Models continuing this PR must not add, remove, check, uncheck, rename, or reorder checkboxes here.

• refackiew

---

Everything below this line was generated by Codex GPT-6.

Created by Codex on behalf of Byron. Byron will review before this is ready to merge.

Change

Large macOS directories could leave one worker waiting inside getattrlistbulk at about 15% of a CPU core. Native traversal also collected an entire parent directory before publishing its entries and child jobs.

Native traversal now streams batches and uses a bounded initial bulk probe to choose how to collect metadata. If the first refill is CPU-bound, bulk enumeration continues with its cached metadata. If two initial refills each spend more time waiting than executing, multiworker walks reopen with ordinary directory enumeration and distribute stat calls through the existing worker pool. The CPU measurement includes kernel time; there is no absolute latency or entry-count cutoff.

The probe holds at most two 64 KiB bulk buffers worth of entries and is discarded only after reopening succeeds, before any entry or child job has been published. This avoids duplicate entries and mixing incompatible directory cursors. Metadata queues are bounded; a full local queue makes the producer process its next batch inline. Parent ordering and optional APFS clone metadata remain supported.

This initial decision deliberately trades continuous adaptation for bounded state: it can miss a later cache transition, and a temporary cold prefix can select stat even if later bulk reads would be fast. CPU waiting also includes descheduling, so the signal is a heuristic rather than a universal crossover guarantee.

Measurements

On the reported live target, alternating final/original/final interactive runs took 18.05 / 34.60 / 17.63 seconds. The final run averaged about 1.24 CPU cores, versus 0.29 for the original whole scan; peak memory fell from 404 MB to 205 MB. The target was changing during investigation, so these timings are not a controlled benchmark ratio.

A stable 218,432-file corpus retained cached performance: three alternating cached runs had medians of 0.402 s original and 0.399 s final. Isolated cached bulk refills used about 99.5–99.8% CPU, while the slow real directory used about 14%, supporting a relative waiting/execution signal. Restricting bulk calls to listing attributes still spent 40.2 of 43.2 seconds inside listing calls, which is why the implementation reopens with ordinary enumeration after the unpublished probe.

Validation

• Regression tests cover timing decisions at different clock scales, bounded probe/backlog memory, streamed child work, parent ordering, and native/stat metadata parity for APFS clones, resource forks, hard links and symlinks.
• make check, make unit-tests, and make journey-tests.
• cargo clippy --workspace --all-targets --all-features -- -D warnings and cargo fmt --check.

Reported issue

$issue-full-auto When using `dua i /Users/byron/dev/github.com/GitoxideLabs/gitoxide.worktree-create/
  target` it scans the folder very slowly with just 15%⠂of a CPU core. I recorded a ⠂
  trace of the final seconds, that includes the first screen refresh as well.      ⠈ ⢀
 ⠈Investigate what's going⢀on and if this can be faster. /Users/byron/Desktop/dua-slow-⠐
  scan.trace