Directly constructed subprocess pipe protocols segfault when callbacks use a non-process owner

Start by reproducing the three constructor-and-callback cases for ReadSubprocessPipeProto and WriteSubprocessPipeProto, then inspect their generated callbacks in uvloop/loop.c at the reported locations. Use the ASan/UBSan findings to trace invalid owner access, and verify that each case raises a Python exception instead of terminating the interpreter.

Summary

ReadSubprocessPipeProto and WriteSubprocessPipeProto accept ordinary integers as constructor arguments, after which the listed protocol callbacks terminate the interpreter.
I realize this is not a realistic input or usage pattern, but I would expect a Python exception rather than a process crash.

Versions

uvloop 0.22.1, CPython 3.12.3, Debian 12 x86_64, glibc 2.36

Reproducer

Each call below reproduces independently in a fresh process.

from uvloop.loop import ReadSubprocessPipeProto, WriteSubprocessPipeProto

ReadSubprocessPipeProto(1, 7).data_received(b"data")
WriteSubprocessPipeProto(1, 7).connection_lost(None)
WriteSubprocessPipeProto(1, 7).resume_writing()

Segmentation fault (core dumped)

ASan/UBSan result

I built uvloop 0.22.1 from source with Clang 18 using ASan and UBSan instrumentation.
ASan reports zero-page reads for data_received() and connection_lost() in their generated Cython callbacks:

ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000e0
The signal is caused by a READ memory access.

    #0 ReadSubprocessPipeProto.data_received
       uvloop/loop.c:130047:177

SUMMARY: AddressSanitizer: SEGV
uvloop/loop.c:130047:177

The connection_lost() variant reports an equivalent read from address 0xd8 at uvloop/loop.c:129583.
For resume_writing(), UBSan first reports misaligned PyObject access in Py_INCREF at uvloop/loop.c:129886, and ASan then reports the resulting read fault.
The sanitizer processes exit with code 134 after ASan aborts.

I found this while fuzzing Python C extension modules.