[BUG]: type_info data races in free threaded Python

[colesbury]

Required prerequisites

• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
• Consider asking first in the Gitter chat room or in a Discussion.

What version (or hash if on master) of pybind11 are you using?

master

Problem description

There are a few related data races in free threaded Python (3.13t) involving detail::type_info.

The most serious (found by @vfdev-5) is that the std::vector<type_info *> in registered_types_py is populated outside the internals lock, so a thread may incorrectly see an empty vector (or other crashes). Victor has a PR that addresses this race (#5419).

The other data races are because some fields in type_info may be modified after creation:

• type_info::implicit_casts: vector is modified when subclasses are defined
• type_info::simple_type: field is set to false when a subclass that uses multiple inheritance is defined

Additionally, a few fields are written after the type_info is exposed in registered_types_cpp/registered_types_py -- I think we want to reorder it so that those fields are initialized earlier.

Finally, there are a few fields that I think are mostly okay in typical usage, but I'm not entirely sure:

• type_info::implicit_conversions: modified for py::implicitly_convertible<A, B>() on B's type_info.
• type_info::direct_conversions: pointed-to vector modified by PYBIND11_NUMPY_DTYPE(type, ...)
• type_info::get_buffer/get_buffer_data: modified by def_buffer()

I think these are okay because they're typically invoked when the type is bound, before the type_info is used by other threads.

Reproducible example code

See test case in https://github.com/pybind/pybind11/pull/5419

Is this a regression? Put the last known working version here if it is.

Not a regression