It doesn't seem very easy to test. This error only occurs for me if some files were added to the folder while RmSync was called. Reproducing this can result in flaky tests, as the error condition is timing-dependent.
I will take a look at how to reproduce this error reliably.

Update: There is already a test for this that is now failing. I will update the test.

Codecov Report

Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 89.09%. Comparing base (1d8593e) to head (55719ed).
Report is 8 commits behind head on main.

@@            Coverage Diff             @@
##             main   #57103      +/-   ##
==========================================
- Coverage   89.09%   89.09%   -0.01%     
==========================================
  Files         665      665              
  Lines      193249   193250       +1     
  Branches    37231    37232       +1     
==========================================
- Hits       172175   172172       -3     
- Misses      13802    13813      +11     
+ Partials     7272     7265       -7     

The behavior of std::filesystem::remove_all seems to differ between operating systems. There is already a unique case for Windows. It may be necessary to introduce this for Linux and macOS.

The libcxx implementation ignores errors when deleting files that can not be deleted:
https://github.com/llvm/llvm-project/blob/251377c47d296000158347d6a1cba2e6b30132a3/libcxx/src/filesystem/operations.cpp#L886-L951
While the libstdc++ returns an error if a file cannot be deleted:
https://github.com/gcc-mirror/gcc/blob/b22f191b7c594b33fb4b4a07769dbf0ca45bc9e9/libstdc%2B%2B-v3/src/c%2B%2B17/fs_ops.cc#L1363-L1409

I will make the required changes and check how the test runs under Windows. But first, I will ask the libcxx folks if this is expected behavior or if it also needs fixing.