Add support for Python 3.15

[dosisod]

This PR adds support for Python 3.15. The cibuildwheel package had to be updated in order for Python 3.15 wheels to build. The relevant documentation has also been updated to indicate support for Python 3.15.

All tests and wheel builds are passing on my fork, except Windows wheels are failing at the "repair wheel" phase. It seems unrelated to the Python updates, as Python 3.11 is failing. Maybe the Windows wheel builds will work on this repo?

Happy to make changes as needed!

[jdavid]

Follows Kimi's review regarding the Windows failure.

---

Blocking: Windows wheel jobs fail (all 3 arches, all Python versions, including cp311)

The error is delvewheel: FileNotFoundError: Unable to find library: git2.dll at the repair
step. Root cause, confirmed by reading both cibuildwheel versions:

• cibuildwheel 3.x: the Windows default repair-wheel-command is an empty string, so no
  repair ever ran on Windows (cibuildwheel 3.4.1 resources/defaults.toml). setup.py:99
  (BuildWithDLLs) already copies git2.dll into the wheel, so wheels were self-contained
  without repair.

• cibuildwheel 4.x: the Windows default changed to delvewheel repair -w {dest_dir} -v
  {wheel} (4.3.1 resources/defaults.toml:73). delvewheel now analyzes pygit2/_libgit2.pyd,
  sees it imports git2.dll, and cannot locate it: without --ignore-existing delvewheel
  disables its in-wheel search (dll_utils.py:340 — the casemap is only built when that
  flag is set), and C:\libgit2_install*\bin is not on PATH. I also diffed delvewheel
  1.13.1 → 1.13.2 (newly pinned by cibuildwheel 4.3.1's constraints): only UTF-8 encoding
  fixes, no discovery changes — so the regression is purely the cibuildwheel 4.x default,
  not a delvewheel bug.

Suggested fix — restore the previous behavior in pyproject.toml:

  [tool.cibuildwheel.windows]
  repair-wheel-command = ""

I verified cibuildwheel 4.3.1 honors an explicit empty string (options.py:914 reads it
with ignore_empty=False) and skips repair in that case (platforms/windows.py:561), moving
the built wheel as-is — exactly the 3.x behavior, with git2.dll still bundled by setup.py.

An alternative is delvewheel repair --ignore-existing -w {dest_dir} {wheel}, which makes
delvewheel recognize the in-wheel git2.dll and still repair any other external deps —
arguably better long-term, but it changes the wheel layout/metadata compared to what you
ship today. Either way, this needs to be resolved in this PR; it can't be waved through as
a pre-existing failure (master's wheels run from 2026-09-30 is fully green).

[jdavid]

Also, the compatibility table in install.rst is wrong, the next release will be 1.21.0

[dosisod]

All green now! Sorry for the delay on this.

Would you like me to squash my changes now, or will you do that on merge? Thanks

[cboos]

Hi, as I'm primarily on Windows, I thought I could contribute some testing. Verified the Windows x64 wheels from run 39282503127 (head 1261088) on a real Windows 11 box. cp311, cp313, cp315 and cp315t (CPython 3.15.0rc2) install in fresh venvs, and import pygit2 works with only System32 on PATH. The bundled pygit2/git2.dll is the one loaded, and LIBGIT2_VERSION is 1.9.7. On the free-threaded build the GIL stays disabled after import. A custom Python OdbBackend reading and writing through callbacks works on all four, including Index.add through cffi. LGTM for the Windows side.