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.06%. Comparing base (1d8593e) to head (2bff9c0).
Report is 34 commits behind head on main.

@@            Coverage Diff             @@
##             main   #57103      +/-   ##
==========================================
- Coverage   89.09%   89.06%   -0.04%     
==========================================
  Files         665      665              
  Lines      193249   193306      +57     
  Branches    37231    37261      +30     
==========================================
- Hits       172175   172159      -16     
- Misses      13802    13826      +24     
- Partials     7272     7321      +49     

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.

CI: https://ci.nodejs.org/job/node-test-pull-request/65352/