Bug: 5.1.2 is missing both cp311 Windows wheels

### Describe the bug

`stringzilla` 5.1.2 is missing both cp311 Windows wheels:

- `stringzilla-5.1.2-cp311-cp311-win_amd64.whl`
- `stringzilla-5.1.2-cp311-cp311-win32.whl`

Every other Python and platform combination in that release has its wheels, including cp311 on macOS, Linux and `win_arm64`, and `win_amd64` for cp310, cp312, cp313 and cp314. See https://pypi.org/project/stringzilla/5.1.2/#files

| Release | cp311 win_amd64 | cp311 win32 | total files |
|---|---|---|---|
| 5.1.1 | present | present | 104 |
| 5.1.2 | missing | missing | 92 |

This looks like the same failure as #319, where cp311 Linux wheels went missing from 4.6.2. The per-version build matrix you introduced to fix that is in place and cp311 is listed:

```yaml
build_wheels_stringzilla_windows_x86:
runs-on: windows-2022
strategy:
fail-fast: false
matrix:
python-version: ["310", "311", "312", "313", "314"]
```

So the matrix is not the problem this time. With fail-fast: false a single failing builder does not stop the others, and the release publishes with the remaining wheels. Nothing appears to check that the uploaded set matches the matrix before publishing, so one flaky builder silently ships an incomplete release.

Downstream effect: stringzilla reaches many people indirectly through albumentations -> albucore -> stringzilla>=3.10.4, so this hits users who never installed it on purpose. On Windows with Python 3.11 pip finds no compatible wheel, falls back to the sdist, and the build fails with "Microsoft Visual C++ 14.0 or greater is required" on any machine without Build Tools. It blocked first-run setup for our Windows users until we pinned 5.1.1.

### Steps to reproduce

On Windows with Python 3.11 (x86-64), in a clean venv:

python -m pip install stringzilla

pip downloads stringzilla-5.1.2.tar.gz instead of a wheel and tries to build it. On a machine without Visual C++ Build Tools it fails with "Microsoft Visual C++ 14.0 or greater is required".

python -m pip install --prefer-binary stringzilla installs 5.1.1 from a wheel, which confirms the missing artifact is the only cause.

### Expected behavior

pip install stringzilla on Windows with Python 3.11 installs a wheel, as it does for every other supported Python version.

Two asks:

1. Could cp311 win_amd64 and win32 wheels be published for 5.1.2, or in the next release? PyPI does allow adding distribution files to an existing version, which would fix it for everyone still resolving a >= constraint without waiting for a new release.
2. Would it be worth failing the publish step when the uploaded wheel set does not match the build matrix? fail-fast: false is right for getting full feedback from a build, but it does mean an incomplete release can ship quietly, which is now the second time cp311 has gone missing this way.

### StringZilla version

v5.1.2

### Operating System

Windows 10 and Windows 11

### Hardware architecture

x86

### Which interface are you using?

Python bindings

### Contact Details

peter@addaxdatascience.com

### Are you open to being tagged as a contributor?

- [x] I am open to being mentioned in the project `.git` history as a contributor

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start with the build_wheels_stringzilla_windows_x86 job and its Python-version matrix, then inspect the release publishing step that uploads the wheel artifacts. Compare the expected matrix entries with the files published for 5.1.2; done means the release process either publishes all listed wheels or clearly prevents an incomplete release.

Written by the indexing model from the issue text.