Fix: Fall back when O_NOATIME is denied opening memory-mapped files on Linux

[mertcancam]

Summary

Allow unprivileged Linux processes to memory-map readable USearch index files owned by another user.

On Linux, memory_mapped_file_t opens files with O_RDONLY | O_NOATIME. The open(2) documentation specifies that O_NOATIME requires either a matching effective UID or CAP_FOWNER; otherwise, open fails with EPERM, even when the file’s normal permissions allow it to be read.

We encountered this issue when an unprivileged process attempted to read a world-readable index owned by root. The failure appeared in strace as:

openat(..., "x-vectors.usearch", O_RDONLY|O_NOATIME) = -1 EPERM (Operation not permitted)

There was no subsequent attempt to open the file without O_NOATIME, so USearch could not map the index.

This change retries the open with O_RDONLY when the O_NOATIME attempt fails with EPERM. This preserves the no-atime optimization where permitted while falling back to normal read permissions otherwise. Other errors and non-Linux platforms remain unaffected.

Similar fixes in other projects

Other projects use the same retry-on-EPERM fallback, or an equivalent approach, for the same reason:

• QEMU’s 9p driver: [hw/9pfs/9p-util.h#L176](https://github.com/qemu/qemu/blob/master/hw/9pfs/9p-util.h#L176)
• Linux overlayfs (proactively avoids the failure via a capability check): [fs/overlayfs/util.c#L681](https://github.com/torvalds/linux/blob/master/fs/overlayfs/util.c#L681)
• vmtouch: [vmtouch.c#L518](https://github.com/hoytech/vmtouch/blob/master/vmtouch.c#L518)

Validation

• Full C++ test suite passes.
• cppcheck passes.