The Nix overlay pins a z3-solver the imported angr rejects, and it takes 14 jobs with it

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

`main` has been red since at least 2026-09-03 because `nix/python-overlay.nix`
pins a `z3-solver` the imported `angr` no longer accepts.

### What fails

`Warm the store` dies in evaluation:

```
error: angr requires z3-solver==5.0.0.0 but nix/python-overlay.nix provides
4.13.0.0; update the `pinned` table
```

That is the overlay's own constraint check at `nix/python-overlay.nix:171`
doing its job. `mono.json` imports angr at `854269112a5ce5b1b356cf6d67bff9abaf986b55`,
whose `pyproject.toml` asks for `z3-solver==5.0.0.0` in both its dependency
lists; `pinned."z3-solver".version` is `4.13.0.0`.

Every Nix lane needs the warmed store, so one evaluation failure takes 14 jobs
down with it. Run `33791598608` on `main` at `e1bc22a` failed 16 jobs; run
`33998126499` on #24, a three-file change to `ci/`, failed the same 14 — the
identical set, which is how this was found.

### The fix is not only a version and three hashes

The wheel platform tags moved between the two releases, so the `platform`
strings in the `wheels` table have to change with them. From PyPI's
`z3-solver` 5.0.0.0 file list, digests converted to SRI:

| system | 4.13.0.0 platform | 5.0.0.0 platform | 5.0.0.0 hash |
| --- | --- | --- | --- |
| `x86_64-linux` | `manylinux2014_x86_64` | `manylinux_2_27_x86_64` | `sha256-VXGUm0er7meTWusF255IrxTtls7aGPb/i3XrOQG7nFQ=` |
| `aarch64-linux` | `manylinux2014_aarch64` | `manylinux_2_38_aarch64` | `sha256-jVpADt0yp0krc//tV1Z3uPCuBEAcaGC32LPHnF/2Cec=` |
| `aarch64-darwin` | `macosx_11_0_arm64` | `macosx_13_0_arm64` | `sha256-N9RM88kMTEYp2KB0tDK78Gww7ZN7dseQiN+dZTSrpQo=` |

5.0.0.0 also publishes `manylinux_2_38_riscv64` and three Windows wheels, and
no longer publishes an x86-64 macOS wheel under the old tag — it is
`macosx_13_0_x86_64` now. Nothing in the table wants those today.

Not verified here: that the components' test suites pass against z3 5.0.0.0.
The comment above `pinned` says z3 4.16's Python binding types broke suites the
last time this moved, so whoever takes this should expect to find out rather
than assume. This report is the evaluation failure and the wheel metadata; it
is not a claim that bumping the pin is sufficient.