Measure the Windows distributive, not the internal build-output archive

[Fedr]

Problem

The Windows leg of the artifact-size stats measured MREDist_<VS_TAG>_<config>.zip, which is
tar --format zip of source/x64/<config> — a CI-internal hand-off: retention-days: 1,
consumed only by update-win-version, then deleted by its cleanup-win-archives job. Nothing
outside CI ever downloads it, and no doc references the name.

Every other platform already measures the shipped package (meshlib_*.deb, *.pkg,
linux-vcpkg-*.tar.xz, the emscripten zip). Windows was the only outlier.

That made the MeshLib Windows Artifact Size chart report a 118.6 -> 306.3 MB jump on #6657,
read as a 2.6x regression in what users download. It was neither:

what	before #6657	after #6657
MREDist_VS19_Release.zip (internal)	118.6 MB	320.1 MB
MeshLibDistVS19.zip (what users download)	545.4 MB	338.2 MB
MeshLibDistVS19-PDB.zip (companion)	-	402.5 MB

The internal archive grew because the 23 new Release linker .pdb files (190.6 MB of today's
320.1 MB) have to ride to the packaging job — make_install_folder.py copies source/x64 into
install/lib, and only then does split_install_pdb.py move them into the companion. So the
old measurement tracked symbol traffic, and moved in the opposite direction from the archive
it was supposed to describe.

Change

Collect the artifact stats in update-win-version, on ${{ matrix.output_zip }} — the main
distributive, after Archive Symbols has already moved the .pdb files out. The exact glob
excludes the -PDB.zip companion (collect_ci_stats.py sums every entry of the stats file).

collect_ci_stats.py only emits a job row when RunnerSysStats-<job_id>.json exists, so the
packaging job now collects runner stats too, and the matrix says which build each distributive
came from:

distributive	compiler	config	build system
MeshLibDistVS19.zip	msvc-2019	Release	CMake
MeshLibDistVS22.zip	msvc-2022	Release	CMake
MeshLibDistVS26.zip	msvc-2026	Release	MSBuild
MeshLibDist-IteratorDebug.zip	msvc-2019	Debug	CMake

Those are the toolchains that produce the MREDist_* inputs
(.github/workflows/matrix/windows-*-config.json). The collector lowercases both values, so the
existing dashboard filter (os='windows' and build_config='release' and build_system='cmake')
keeps matching the VS19 and VS22 rows with no dashboard change — it just describes the
distributive now instead of the build directory. VS26 stays on msbuild, as its row did before.

A distributive spans both configurations; each row is tagged with the Release build behind it
(Debug for the Debug-only IteratorDebug package), which is also what the row carried before.

Trade-off

update-win-version runs only when build-release-win is set — schedule, full-ci, or the
build-release-windows label — not on every push to master. The Windows series therefore
drops from ~1 point per master push to ~1 per nightly. That is the real cadence at which a
Windows distributive is produced; the denser series was measuring something else.

Also gains a side effect worth having: update-win-version now appears in the CI-stats job
table, so its duration and step timings become visible like every other build job.

Testing

Labelled build-release-windows + upload-binaries so update-win-version actually runs, with
the other platforms disabled. Verify in the run: each of the four packaging jobs uploads
ArtifactStats-<job_id>.json and RunnerSysStats-<job_id>.json, and the collect-stats job
prints an artifact_size for them matching the MeshLibDist*.zip sizes.

[oitel]

Revert the overly detailed change.

[oitel]

Drop the redundant comment.