fix(build): stop dropping the MSVC CRT from Windows packages (#650)

[neuregex]

Related Issue

Closes #650

Description

#650 diagnosed the launch failure as a bad SxS manifest declaring mozglue as a win32 assembly dependency. That part is already gone. On a current build (v152.0.4-beta.25, win.x86_64) there is no embedded manifest at all — zero matches for assemblyIdentity, dependentAssembly, urn:schemas-microsoft-com:asm, trustInfo or requestedExecutionLevel — and mozglue.dll appears only in the import table, which is correct for a private DLL sitting next to the binary.

But the same user-visible symptom (spawn UNKNOWN, process exits instantly, nothing on stdout) is still reachable through a second, unrelated path: the package can ship without the MSVC CRT.

package-windows pulls the CRT out of the mozbuild VS tree with:

~/.mozbuild/vs/VC/Redist/MSVC/14.38.33135/$(vcredist_arch)/Microsoft.VC143.CRT/*.dll

That pins one redist version (14.38.33135) and one toolset (VC143). Windows builds cross-compile on ubuntu-24.04 and get their toolchain from make mozbootstrap, so if the version on the runner differs the shell never expands the glob and make passes the literal pattern through. add_includes_to_package() then hits:

for include in includes or []:
    if os.path.exists(include):     # <- no else branch

…and skips it silently. The package builds, uploads and releases with no CRT, while camoufox.exe imports VCRUNTIME140.dll, VCRUNTIME140_1.dll and MSVCP140.dll — so it cannot start on a machine that doesn't already have the Visual C++ Redistributable installed.

That also explains why this reads as a "clean systems" bug: developer machines almost always have the redistributable pulled in by other tooling, so it launches fine there and dies on a fresh install.

Scope note: I observed the missing DLLs on a v152.0.4-beta.25 win.x86_64 package produced by this repo's build workflow, not on the official release asset (469 MB, and range requests against the signed asset URL didn't cooperate). Whether a given official build is affected depends on the toolchain version present on the runner at build time — worth checking a current release artifact for VCRUNTIME140.dll. The failure mode itself is in the packaging code either way.

Changes

1. Makefile — glob the redist and toolset versions (MSVC/*/…/Microsoft.VC*.CRT/*.dll) instead of pinning them, so a toolchain bump can't silently drop the CRT.
2. scripts/package.py — a missing --includes entry is now fatal. An unexpanded glob fails the build loudly instead of quietly producing a package that can't start.

Type of Change

• Bug fix
• New feature
• Documentation update
• Other

Testing

• Confirmed the shipped tree contains no VCRUNTIME140*.dll / MSVCP140.dll anywhere, while camoufox.exe imports all three (they resolve from System32 on machines that have the redistributable).
• Confirmed there is no embedded SxS manifest in the current binary, i.e. the originally reported cause is already resolved.
• python -m py_compile scripts/package.py passes.
• The new guard is a no-op for a correctly resolved build: every existing --includes entry (settings/chrome.css, settings/camoucfg.jvv, settings/properties.json, and the CRT glob when it expands) exists, so nothing changes except that a broken glob now fails instead of shipping.

I don't have a Windows cross-compile environment to run a full make package-windows end to end — if you can trigger a build off this branch, the CRT DLLs should now appear in the archive (and the build should fail loudly if they can't be found).

Fingerprint Report

This PR only touches the packaging step (Makefile + scripts/package.py); no patches, browser source or pythonlib/ behaviour changes, so there's no fingerprint surface for it to affect. Happy to run the suites anyway if you'd like them attached.