RFC: Drop MSVC as a supported compiler on Windows (keep clang-cl)

Continues the 2026-08-13 IRC meeting discussion.

## Proposal
Stop supporting MSVC (`cl.exe`). Native Windows builds use `clang-cl.exe` (#31507).
Release binaries are unaffected (mingw-w64 cross-compile in Guix).

## Motivation
- MSVC is the only compiler we use that we cannot fix: no upstream patches, ineffective bug reporting. Also see historical ICE [workarounds](https://gist.github.com/hebasto/aa42915f88faa4a0ee02655bb55ee624).
- As far as we know, every MSVC-specific issue found so far has been a compiler bug, not a codebase bug. More of them are expected as we adopt C++23/26.
- Windows keeps two toolchains (mingw-w64 cross, clang-cl native); CI job count unchanged.
- clang-cl still uses the MS STL, so standard-library diversity is retained.

The only drawback is reduced compiler diversity in what the codebase is built and tested against.

## What changes (commit 96d2380dc40e703e342dc0fad5d294cc49b25ff9 in #31507)

**Removed:** MSVC CI jobs; MSVC docs; MSVC-specific CMake flags and diagnostics.

**Kept:** CMake does not reject MSVC; source-level `_MSC_VER` guards (shared with clang-cl).

**Policy:** MSVC is unsupported, no CI, MSVC-only workarounds not accepted.

#24773 will be closed, as no longer needed to fix performance issues.

## Users' perspective
From the users' perspective, the binaries produced by MSVC are strictly inferior.

Start by reviewing commit 96d2380dc40e703e342dc0fad5d294cc49b25ff9 and the related work in #31507. Check the MSVC CI jobs, documentation, CMake flags, and diagnostics described in the proposal, and confirm how #24773 is affected. Done means the support policy and all listed removals are agreed and consistently represented.

Written by the indexing model from the issue text.