[Copilot]

PyEventLoop::_getLoopOnThread read asyncio_running_loop from a local copy of CPython's private _PyThreadStateImpl at a compiled-in offset. Python 3.14.4 added a pointer to the public PyThreadState, so a wheel built against 3.14.4+ headers reads the neighbouring asyncio_running_task on 3.14.0–3.14.3. The Task is then treated as the loop, and awaiting any JS promise crashes. The reverse mismatch would break the same way.

• Current thread: _getLoopOnThread now calls asyncio._get_running_loop() instead of reading the struct. This fixes the crash path and no longer depends on the patch version. It applies to all Python versions, not only 3.14.
• Other threads: getMainLoop() from a helper thread still needs the struct read, because the Python API only works for the current thread. For 3.14 builds, the runtime Py_Version is now compared with the build-time PY_VERSION_HEX across the 3.14.4 boundary. If they straddle it, the read is skipped and the call returns the usual "cannot find a running Python event-loop" error instead of reading the wrong field.

import asyncio, pythonmonkey as pm

async def main():
    return await pm.eval('Promise.resolve(1)')

print(asyncio.run(main()))  # segfault / access violation on 3.14.0–3.14.3 before; prints 1.0

For review:

• I did not cache the main loop, because a cached loop goes stale across repeated asyncio.run calls.
• On a layout mismatch, helper threads calling getMainLoop() now get an error rather than a crash.
• This has not been built or tested yet, and no regression test is added, since reproducing needs a 3.14.0–3.14.3 interpreter.

• Fixes Segfault / access violation awaiting any JS promise on Python 3.14.0–3.14.3 (thread-state offset from 3.14.4+ headers) #515