Finish windows-abi: repin, gate it, and add the clang-cl and MSVC legs

Follow-up to #28, which shipped the MinGW half of the Windows stack-ABI check. Three things it left behind.

1. Pins name a commit that is not on main

All 62 internal pins name e39ce4045d855e89f9f1e2475562b4ba7a38cf33, the last commit of the PR branch. #28 was squash-merged, so main is a single commit df5060f with parent 31ad368 — and e39ce40 is not an ancestor of main.

$ git merge-base --is-ancestor e39ce404… origin/main
e39ce40 is NOT an ancestor of main

They still resolve today: GitHub keeps PR-branch commits reachable through refs/pull/28/head, and the action is present at that SHA. But that is a retention detail, not a guarantee, and it is out of step with the convention that pins name a release commit.

Repin all of them to the release commit. Worth confirming at the same time that check_internal_pins.py is actually happy on main — it does git show <sha>:<path>, and in a shallow clone of main that SHA is not necessarily fetched, so it could fail or pass vacuously depending on what the checkout brought down. The first main self-check after the merge (run 43 on df5060f) was still queued when this was written; its result answers that.

2. windows-abi is outside the self-check / all gate, on a reason that no longer holds

#28 deliberately excluded it, and said why:

Two of the three rungs fail it today — GCC 15 and 16 are the compilers that emitted the bad store — so a red leg is the check working, and gating on it would pin self-check red until an upstream fix lands.

That expectation was wrong. Once the corpus was fixed to actually reach the stack, all three rungs passed, and have for five consecutive runs — 24, 20 and 24 wide stack accesses on 15.3.0, 16.2.0 and 17-SVN, every one of them vmovdqu. So the exclusion has no justification left, and an ungated leg means a future regression in the checker itself goes unnoticed.

One thing to settle before flipping it. --require-wide-stack fails a run that produced no wide vectors at all, and the windows-2022 pool is heterogeneous:

run 38:  __AVX2__  __AVX512F__  __AVX__  __SSE4_2__
run 42:  __AVX2__               __AVX__  __SSE4_2__

Same workflow, same runner label, different CPU. A machine with no AVX at all would redden the gate for an environmental reason rather than a finding. Gating wants that case distinguished first — either a distinct exit code, or treating "no wide vectors available" as a skip rather than a failure.

3. clang-cl and MSVC legs

The workflow is called windows-abi rather than mingw-abi because clang-cl and MSVC target the same ABI and belong in it. Neither is implemented; it is MinGW only.

Known blockers:

• Both drivers need a vcvars environment to run outside an IDE shell.
• clang-cl pairs with llvm-objdump, which the checker already handles — the self-test fixture covers both GNU and llvm rendering, including the two-command`s-complement vs signed realignment mask difference that bit it once.
• MSVC has no objdump at all. It would be dumpbin /disasm, whose output format the checker has never seen. That needs its own fixture case in cases.s before any verdict from it is trustworthy — the whole point of the self-test is that an unrecognised format makes the checker match nothing and pass everything.
• MSVC has no /arch:native, so the ABI runner should pass /arch:AVX2 explicitly to ask the question at a comparable width.

Why this is worth finishing

The MinGW half already earned its place. Pointed at rhalbersma/bit_set's own build tree it found 41 latent general-protection faults across three toolchains — including 15, 12 and 14 in Release, a configuration that had been green throughout and that nobody suspected. Those were vmovdqa stores to 16-but-not-32-aligned frame slots in functions that never realigned, and they faulted only when rsp happened to land unfavourably, which is why they survived three pull requests of manual narrowing.

There is no reason to assume clang-cl and MSVC are clean on the same target. Nobody has looked.

Read the workflow from #28, check_internal_pins.py, and the existing cases.s fixtures first; confirm the main self-check result and how shallow checkout affects pin validation. Trace the windows-abi gate and its handling of no-wide-vector runs before adding clang-cl and MSVC coverage. Done means all pins use the release commit, the gate is reliable, and MSVC has a trusted dumpbin fixture and passing CI leg.