fix(rw): forget the async lock's worker after fork

[gaborbernat]

test_async_read_write_lock_fork_behavior[held] hung on PyPy 3.11 in #827's CI. The hang is in filelock, not the test.

A forked child that exits normally runs the concurrent.futures exit hook, which wakes every registered executor worker by putting None on its queue. The worker AsyncReadWriteLock owns does not exist in the child. On PyPy that queue is the pure-Python _PySimpleQueue, whose lock the worker takes again right after finishing an operation. A fork that lands in that window leaves the lock held forever in the child, and the exit hook's put blocks. A stack dump of a hung child shows it parked there.

CPython 3.12+ clears that registry in the child (os.register_at_fork(after_in_child=_threads_queues.clear)); PyPy 3.11 ships without it. The lock's after-fork hook now drops its own worker from the registry the same way.

Running the test's fork script under PyPy hung 4 of 1920 times before this change and 0 of 5760 after. The full suite passes on CPython 3.14 (100% coverage) and PyPy 3.11.