Closes #697

On Windows the server can exit before it starts, with an `ImportError` about `_greenlet` and a DLL that is never named. greenlet moved its Windows builds from Appveyor to GitHub Actions in 3.3.1 and lost the `GREENLET_STATIC_RUNTIME` flag on the way, so `_greenlet.pyd` links the C++ runtime dynamically and needs `MSVCP140.dll`. That DLL comes with the Visual C++ redistributable and no Python distribution ships it, so a machine without the redistributable cannot load greenlet at all. We never call greenlet ourselves; patchright imports it unconditionally on the async-only path, which is why the failure lands before any of our code runs.

The probe lives in the package `__init__` because that is the only place both entry paths reach before `cli_main` pulls in patchright, and it costs nothing on the path that matters since patchright imports the same module moments later. It runs on Windows only. It matches on `DLL load failed`, a prefix CPython formats itself in `dynload_win.c` and keeps English on every install, and re-raises anything else untouched so a merely absent greenlet is not handed advice about a redistributable. The message names both routes, because installing the redistributable needs administrator rights that a `uvx` user may not have, and the stopgap it offers is marked x86-64 only since there are no Windows ARM64 wheels before 3.3.1. Two README troubleshooting sections gain the same pointer.

The upstream fix is filed as python-greenlet/greenlet#525 with the one-line restore in python-greenlet/greenlet#526, where CI now builds x64 and ARM64 wheels that import nothing beyond `KERNEL32.dll` and the Python DLL again. That does not retire this guard: the affected wheels stay on PyPI, and any resolver landing on one reproduces the failure.

Eight tests cover the translated message, the preserved cause, the re-raise, the platform gate and the import ordering, and they run on every platform because the reasoning about a Windows failure should not need a Windows machine; full suite green.

See also: #688

## Synthetic prompt

> On Windows without the Visual C++ redistributable the server dies at import with `DLL load failed while importing _greenlet`, because greenlet's wheels stopped linking the C++ runtime statically in 3.3.1. Add a Windows-only startup probe that turns that bare ImportError into a message naming `MSVCP140.dll` and the redistributable, with a stopgap for machines without admin rights. Put it where both entry paths reach it before patchright is imported, keep the detection locale-independent, re-raise unrelated import failures unchanged, and add README troubleshooting entries plus tests that run on every platform.

Generated with Claude Opus 5 high + Sol 5.6 xhigh

Closes #688

greenlet's Windows wheels stopped carrying the C++ runtime inside the
extension when its builds moved from Appveyor to GitHub Actions and
`GREENLET_STATIC_RUNTIME` was dropped along the way. From 3.3.1 the
published `_greenlet.pyd` imports `MSVCP140.dll`, which ships with the
Microsoft Visual C++ Redistributable and with neither the python.org
installer nor the python-build-standalone builds `uv` installs.
patchright imports greenlet unconditionally, so on a Windows machine
without that redistributable the server died before its entry point ran.

python-greenlet/greenlet#526 restored the variable and released as
3.5.5. This lock still carried 3.5.1, and the MCPB bundle starts through
`uv run --project`, so every bundle kept installing an extension that
needs a DLL the machine may not have. Raising the pin removes the
problem for that path; `uvx` resolves fresh and already gets 3.5.5. The
startup guard from #698 stays as it is: the affected wheels remain on
PyPI for good, a greenlet built from source can need that DLL at any
version, and nothing forces a third-party install to honour this lock.

Verified by reading the PE import table of the published wheels: 3.5.1
imports `MSVCP140.dll`, `VCRUNTIME140.dll` and `VCRUNTIME140_1.dll`,
while 3.5.5 imports `python312.dll` and `KERNEL32.dll` alone, on
`win_amd64` and `win_arm64` both.

## Synthetic prompt

> greenlet 3.5.5 shipped the upstream fix for the Windows wheels that
need MSVCP140.dll. Raise our lock to it, and update the README
troubleshooting entries and the greenlet_runtime docstring to name the
released fix instead of the open PR. Keep the startup guard.

Generated with Claude Opus 5 high