Bump pip to 26.2.1 to clear PYSEC-2026-3721

[WhatsYourWhy]

Fixes the dependency audit failure in the 2026-08-24 scheduled run
(32700028621).

What broke

Not a regression. Nothing changed since the 08-17 green run — a new advisory
landed against an existing pin:

PYSEC-2026-3721 / CVE-2026-13346, pip 26.1.2, fixed upstream in 26.2. pip
mishandled doubly-encoded package URLs from an index, allowing files to be
written to arbitrary paths on disk even when installing wheels.

Exposure is limited: exploiting it requires a malicious index, not merely a
malicious package, and pip is in the lock only as a transitive dependency of
pip-api and pip-tools under --allow-unsafe. But README.md publishes
pip install --require-hashes -r requirements.lock.txt as an install path, so
the pin is the fix.

The audit job is schedule/manual only, so this was never blocking PRs.

The change

pip 26.1.2 → 26.2.1 in requirements.lock.txt. Three lines, plus a CHANGELOG
entry.

Bumped in place rather than by rerunning pip-compile, deliberately.
Regenerating with --upgrade-package pip on a Windows / Python 3.14 machine
produced the intended pin but also rewrote the Linux/3.12 resolution the file
records: retitled the header, churned two # via comments, and added an
unmarked colorama==0.4.6, which is required only on win32. Committing that
would bake a platform-specific resolution into the lock — the same mistake as
4fbab87's Windows-only golden hashes, which a71d477 reverted.

Verification

• Both hashes verified against the PyPI JSON API for 26.2.1 — sdist and wheel,
  not yanked, requires-python >=3.10 matches the project floor. They match
  what pip-compile independently emitted.
• Queried OSV for all 56 pins in the lock: clean. The same query against the
  pre-change lock reports PYSEC-2026-3721 on pip 26.1.2, confirming the
  check works and that this change is what clears it.
• pytest -q: 237 passed.
• Line endings confirmed LF on both touched files.

Known, pre-existing

pip-audit -r requirements.lock.txt cannot run on Windows against this lock,
before or after this change: pip resolves colorama for win32 and
--require-hashes then rejects it as unpinned. Confirmed identical on the
unmodified lock. CI runs the audit on ubuntu-latest where it does not apply,
so nothing is blocked — but the audit is not locally reproducible on Windows.
Worth fixing separately.

🤖 Generated with Claude Code