GeezerVison

Summary

Fixes finding (124) from #149816: a use-after-free when a free-threaded dict is resized while another thread does lock-free lookups (including specialized LOAD_ATTR_WITH_HINT).

Root cause

On resize of a shared dict, the old PyDictKeysObject / values array is retained via QSBR so concurrent lock-free readers can still touch the table memory. Those tables previously kept live me_key / me_value pointers after ownership was transferred to the new table (or released on clear). A later update of the dict can free those objects while a reader still holds a stale table pointer and tries to incref them — UAF / ABA.

Fix

Structural hardening of the reclaim path, not a one-line band-aid:

1. dictkeys_clear_entries / free_keys_object / free_values: clear entry slots before QSBR-delayed free so stale readers cannot revive transferred objects.
2. dictkeys_decref: snapshot then null slots before XDECREF, so concurrent readers cannot follow a pointer we are about to free.
3. Thread-safe key compares: a NULL me_key under an active index is treated as DKIX_KEY_CHANGED (force locked retry) rather than a false miss — necessary so poisoning does not surface as spurious KeyError / AttributeError.
4. lookup_threadsafe_unicode and _LOAD_ATTR_WITH_HINT: re-validate ma_keys (and the slot value) after acquiring a reference, matching _Py_dict_lookup_threadsafe. Covers the deferred-refcount try-incref path that skips slot re-validation.

Tests

• test_racing_load_attr_with_hint_and_resize
• test_racing_dict_resize_and_lookup

Both stress concurrent resize + lock-free / specialized reads under free-threading (and TSAN in local builds).

Test plan

• ./python.exe -m unittest test.test_free_threading.test_dict.TestDict test.test_free_threading.test_races.TestRaces (×5, free-threaded + TSAN)
• Stress repro for attribute load vs resize (50 trials, 0 failures)
• CI free-threading / TSAN jobs on this PR

• Issue: 22 free-threading race conditions #149816