This is revision of GH-153402.

The issue was a race between ScandirIterator_iternext() and ScandirIterator.close(): one thread could be inside readdir() / FindNextFileW() while another thread closed the underlying DIR * / Windows handle.

Changes

• Add a free-threaded-only mutex to ScandirIterator.
• Use it to serialize access to the native directory stream / handle.
• Keep Py_BEGIN_ALLOW_THREADS around readdir(), FindNextFileW(), closedir(), and FindClose(), preserving existing GIL-enabled behavior around potentially slow OS calls.
• Make the mutex and lock/unlock operations no-ops in GIL-enabled builds.
• Avoid holding the mutex while creating Python objects or setting Python exceptions.
• Add free-threading regression tests for concurrent access patterns that previously could crash.

Notes

This change is intended to prevent crashes and memory corruption. It does not document or guarantee os.scandir() iterators as generally thread-safe.

A PyMutex is used rather than critical sections because critical sections may be suspended across Py_BEGIN_ALLOW_THREADS; the native iterator must remain protected while the OS directory iteration call runs without the GIL.

• Issue: Segfault between os.scandir iterator's close() and __next__() on the dirp handle #152754