Fix three CI failures: a stale black, my scratchpad path, an impossible check

First push of this branch in a while, and CI found three things.

BLACK VERSION DRIFT. The repo pins black ^24.3 (24.10.0 locked) and the local
environment has 26.1.0, whose stable style differs. An earlier commit titled
"satisfy the black gate" reformatted five tui_v3 screens with 26.1.0, which
UNformatted them as far as CI was concerned — the fix made the gate worse.
Everything is now formatted with 24.10.0, the pinned version, reproducing
CI's six files exactly before and zero after. scripts/mutation_test.py is in
there because I wrote it this session and never ran black on it at all.

MY SCRATCHPAD PATH IN requirements.lock. pip-compile records the command that
generated a lockfile in its header, and when I regenerated it during the
dependency-vulnerability fix I compiled to a temp path and copied the result
in. That baked an absolute path from my machine into a committed file, so
CI's regenerate-and-diff could never match. Regenerated with CI's exact
command on Python 3.11; only the two header lines change, so the dependency
set was never wrong.

AN UNSATISFIABLE LOCKFILE CHECK. Separately, and not caused by me: the step
regenerated the lockfile and diffed it on every matrix entry, including
Windows on 3.10 while Linux and macOS use 3.11. pip-compile resolves
version-conditional dependencies per interpreter, so those two produce
genuinely different files — 135 lines apart here, argon2-cffi-bindings among
them. One committed lockfile cannot equal both outputs, so whichever version
it was built on, the other job failed. Verification now runs once on
Linux/3.11, the canonical generator; every platform still installs from the
lockfile with --require-hashes, which is the part that had to stay everywhere.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN

.github/workflows/python-ci.yml

@@ -76,12 +76,25 @@ jobs:
           key: ${{ runner.os }}-pip-${{ hashFiles('requirements.lock') }}
           restore-keys: |
             ${{ runner.os }}-pip-
-      - name: Verify lockfile and install dependencies
+      # Regenerating the lockfile and diffing it proves the committed file
+      # really came from src/requirements.txt. It can only be done on ONE
+      # interpreter: pip-compile resolves version-conditional dependencies
+      # per Python version, so 3.10 and 3.11 produce genuinely different
+      # files (argon2-cffi-bindings among others), and a single committed
+      # lockfile cannot equal both. Run as written across this matrix the
+      # check was unsatisfiable -- whichever version the lockfile was built
+      # on, the other job failed. Linux/3.11 is the canonical generator, so
+      # the verification lives there.
+      - name: Verify the lockfile matches src/requirements.txt
+        if: runner.os == 'Linux'
         run: |
           python -m pip install --upgrade pip
           pip install pip-tools
           pip-compile --generate-hashes --output-file=requirements.lock src/requirements.txt
           git diff --exit-code requirements.lock
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
           pip install --require-hashes -r requirements.lock
       - name: Run dependency scan
         run: scripts/dependency_scan.sh --ignore-vuln GHSA-wj6h-64fc-37mp --ignore-vuln CVE-2025-62727