[WIP] Build free-threaded (cp313t/cp314t) wheels and declare GIL-free support

[dance858]

Closes #18.

What

• bindings.c: on free-threaded CPython, call PyUnstable_Module_SetGIL(module, Py_MOD_GIL_NOT_USED) after module creation so importing _sparsediffengine no longer re-enables the GIL. No-op on regular builds.
• CI: add an abi matrix axis ("" / "t"), build cp314t wheels, set CIBW_ENABLE=cpython-freethreading, and extend the wheel test to assert sys._is_gil_enabled() is still False after import on the t build. Artifact names get the t suffix.
• CI: run pip/twine via python -m in the wheel-check step (one macOS job failed there with pip: command not found).
• README: document the thread-safety contract.

No 3.13t wheel. NumPy >= 2.5 ships no cp313t wheels on any platform, so a 3.13t build has to compile NumPy from source in the isolated build env. In the first CI run that failed on macOS, took 6 minutes on Windows, and was still running after an hour on Linux aarch64 under QEMU. Free-threading users on 3.13 would hit the same NumPy problem at install time anyway.

Why it is safe to declare GIL-free

Audit of the engine (submodule at d8cb9b8) and the bindings:

• nm on libdnlp_diff.a shows no writable data/bss symbols. The only globals in the engine source are the SP_TRACK_MEMORY byte counters, which the wheel build does not enable. No function-local statics, no non-reentrant libc calls.
• All refresh/version counters (values_version, jacobian_csc_seen, csc_seen, transpose_seen) live inside the owning matrix or expr node.
• Every problem and expr owns its buffers. variable forward, problem_update_params, new_parameter and new_problem memcpy their inputs; every wrapper copies results into fresh NumPy arrays. No Python memory is aliased across calls.
• The only static state in the bindings is the NumPy-init flag and the module def, written once at import under the import lock.
• OpenBLAS is safe for concurrent calls.

Caveat, documented in the README: expr refcounts are plain ints, so one expr/problem capsule must not be used from two threads at once. That is the same contract as under the GIL, which only serialized individual calls and never protected against interleaved use of one object.

Verification

• Both code paths compile cleanly with -Wall -Wextra (regular headers, and with Py_GIL_DISABLED defined).
• Built the cp314t extension against Homebrew python3.14t 3.14.7: import keeps the GIL disabled (the exact check CI now runs).
• 16 threads x 200 evaluations on distinct problems (forward, jacobian, hessian over exp/sin/log/sum) are bit-identical to a single-threaded reference, across 5 runs, on both the free-threaded and the regular 3.14 build.
• First CI run: the cp314t wheels built and passed the GIL check on Linux x86_64, Windows, and macOS x86_64 + arm64 (universal2).

🤖 Generated with Claude Code

https://claude.ai/code/session_013aQs1u37EG6XTHFrcaBRkA

[Transurgeon]

instead of this, we should maybe just add 3.14t?