Process-wide barrier implemented as thread_get_state sometimes hangs in Rosetta

`thread_get_state` appears to be fairly fragile when called under Rosetta emulation.
The implementation needs to reconstruct x64 register state from the actual arm64 state and it is possibly a fairly complex routine. Possibly involves taking kernel locks - I can only guess.

The end result is that, depending on the state of other threads, the caller and the target thread both could hang.

Examples of the vulnerable thread states:
- another thread does another process-wide-barrier call (not sure it must be the target thread or any other thread).
Taking a global lock around calling PW barrier can mitigate this scenario.

- another thread is forking.
This is more rare. The global lock does not help here.

Start with the process-wide barrier implementation and the thread_get_state call path, then reproduce the hangs under Rosetta with concurrent process-wide-barrier calls and forking. Done means both reported vulnerable thread-state scenarios no longer hang; the issue names no specific files or tests.

Written by the indexing model from the issue text.