Spike static-liburing ring lifecycle

[bright2227]

Stack

This PR is stacked on #13 and targets agent/add-uringcore-skeleton. Review only commit 467543c; after #13 merges, this PR can be retargeted to main.

What changed

• add _uringcore_liburing.Ring with the same lifecycle API as the raw-syscall spike
• initialize and tear down rings through the pinned liburing submodule
• statically link libs/src/liburing.a, avoiding a runtime liburing.so dependency for this module
• add equivalent lifecycle and queue-size validation tests
• package liburing's MIT notice
• record the initial development-build size comparison

Why

Phase 1 requires both viable ring-management routes to be spiked before selecting the production native core. This gives the raw-syscall and static-liburing routes the same API and test boundary so the next decision record can compare them directly.

Impact

The existing CFFI proactor remains active, so there is no user-facing event-loop behavior change. This experimental extension requires the pinned submodule to be configured and built in a source checkout. Packaging vendored sources for standalone wheel builds remains explicit follow-up work if this route is selected.

The local CPython 3.12 x86-64 development builds measured 35,152 bytes for raw syscalls and 109,840 bytes for static liburing. Release-build measurements are still required.

Validation

• /usr/bin/gcc -fsyntax-only -Wall -Wextra -Werror -I/usr/include/python3.12 -Ilibs/src/include src/uringcore_liburing.c
• .venv/bin/ruff check setup.py tests/unit/test_uringcore_liburing.py uringloop/_uringcore_liburing.pyi
• .venv/bin/ruff format --check setup.py tests/unit/test_uringcore_liburing.py uringloop/_uringcore_liburing.pyi
• .venv/bin/mdformat --check docs/phase1-static-liburing-spike.md
• .venv/bin/pytest tests/ -v — 33 passed
• uv build --wheel --sdist
• ldd uringloop/_uringcore_liburing.cpython-312-x86_64-linux-gnu.so — libc only; no liburing dependency