borg2: segfaults when running the testsuite under cygwin

[ThomasWaldmann]

borg 2.0.0b23.dev403.g33c31ded4

pytest --benchmark-skip

[ThomasWaldmann]

Looks like blake3-py is broken. It built, but it crashes when used.

[ThomasWaldmann]

Root cause found, and it is not a borg bug: it is an ABI mismatch in the blake3 Rust crate on Cygwin.

Reported upstream: BLAKE3-team/BLAKE3#578

gdb puts the crash in blake3's hand-written SIMD assembly:

Thread 1 "python3.12" received signal SIGSEGV, Segmentation fault.
0x000000053e2e52c5 in blake3_compress_xof_sse41 ()
#1  blake3::platform::Platform::compress_xof ()
#2  blake3::OutputReader::fill ()
#3  blake3::Blake3Class::digest ()

The blake3 crate's build.rs chooses the assembly flavour via
CARGO_CFG_TARGET_OS == "windows", but x86_64-pc-cygwin reports target_os="cygwin" /
target_family="unix", so it assembles the System V files (c/blake3_*_x86-64_unix.S) for a
target that uses the Microsoft x64 calling convention. The routines then read their arguments
from the wrong registers and crash on the first call — so any blake3 hashing segfaults, keyed or
not, from 3 bytes upwards. benchmark_cmd_test.py::test_benchmark_cpu is simply the first test that
touches blake3; the segfault kills the whole pytest process, which is why the run died at ~2%.

(The same bug was fixed for the C library's CMake build in BLAKE3-team/BLAKE3#455, but the Rust
build.rs never got the equivalent change.)

Workaround — rebuild blake3-py so it uses Rust/C intrinsics instead of the hand-written assembly
(SIMD performance is retained):

CARGO_FEATURE_PREFER_INTRINSICS=1 pip install --force-reinstall --no-binary blake3 blake3==1.0.9

Verified correct afterwards: official empty-input test vector matches, one-shot / incremental /
max_threads=AUTO / keyed digests agree for input sizes 0 to 5 MB, and extended output
(digest(length=131), the path that crashed) works. With that in place
benchmark_cmd_test.py passes and the test suite runs past the crash point.