Summary

Reject append mode for CuFileDriver instead of pretending it provides safe append semantics.

What changed

• reject open(..., "a") with a clear std::invalid_argument
• reject existing file descriptors that were opened with O_APPEND
• update the C++ and Python filesystem docs to say append mode is unsupported
• add a regression test for both string-based open and raw-fd open with append mode

Why

CuFileDriver exposes explicit-offset pread() / pwrite() APIs. That makes append mode a poor fit.

The obvious alternative would be to add O_APPEND, but that is not actually safe here:

• POSIX defines pwrite() as an explicit-offset write
• the Linux pwrite(2) man page documents that opening a file with O_APPEND causes pwrite() to append regardless of the supplied offset

So adding O_APPEND would make this API more surprising and more dangerous, not less. Rejecting append mode is the cleaner behavior.

Validation

• added regression coverage in test_cufile.cpp
• ran git diff --check
• attempted local CMake configure, but this machine cannot build the project because FindCUDAToolkit fails to locate nvcc