package: pin the chip model at v1.3.1, which Windows can open

[A13xB0]

Closes #632. Pairs with MeshBench/virtual-sx1262#1, which is merged and released as v1.3.1.

What was wrong

v1.3.0's Windows DLL imported libstdc++-6.dll — present inside the MSYS2 environment it was built in, and almost nowhere else. So on any ordinary Windows machine neither emulator could open the chip model:

qemu-system-xtensa.exe: sx1262: cannot load the chip model at
...\libvirtualsx1262.dll: The specified module could not be found.

which names the DLL rather than the dependency behind it. Renode reaches the same library through LoadLibraryW and failed identically, so this was every emulated board on Windows, ESP32 and nRF52 alike. It surfaced three steps downstream as firmware started but never connected within 40s, which reads as flaky emulation rather than a missing file.

Nothing was lost in packaging. release.yml staged exactly what build.sh produced and package.yml shipped exactly what it unpacked — I rebuilt v1.3.0's source with the unmodified flags and got the same imports as the shipped artefact. The build asked for a dynamic runtime on a platform that has none.

What this changes

The pin, and the catalogue's digests and sizes beside it, as the rule at the top of emulator-pins.env requires:

	v1.3.0	v1.3.1
linux-amd64	33f4453c… 26,340 B	7e04041a… 26,335 B
darwin-arm64	362ed99e… 19,118 B	167e471b… 19,119 B
windows-amd64	176b2962… 28,685 B	90621299… 146,549 B

The Windows tarball grows from 28 kB to 143 kB. That is the static runtime, and the whole cost of the fix. Same ABI (1.3), same model — only the Windows link changed; the DLL now imports kernel32 and msvcrt and nothing else.

Verification

Against the published v1.3.1 artefact rather than a local build, on Windows 10 Home 22H2:

• downloaded virtual-sx1262-windows-amd64.tar.gz from the release, sha256sum -c against its published .sha256: OK, and the digest matches what this PR puts in the catalogue
• its DLL's import table: KERNEL32.dll, msvcrt.dll — nothing else
• dropped in place of the shipped DLL in a v0.0.8 install, probe cache cleared:

board.probe Generic_E22_sx1262
  v1.3.0   boot  failed   firmware started but never connected within 40s
  v1.3.1   boot  passed   attached and answering

The node then pins its board image properly — firmware_board: "Heltec_v3", which stayed empty for as long as the boot was failing — and board.screen reports a real 128x64 SSD1306 instead of refusing.

Not in this PR

The bundle still cannot tell a loadable DLL from an unloadable one. package.yml runs file on it, which passes happily on either, and setup.check reports the toolchain row ready on the strength of the path existing — both were green through this entire bug, on three platforms, for a release. The upstream PR adds an import check where the DLL is built; the equivalent here would catch a bad artefact arriving from anywhere rather than only from a build we control. Worth doing, and worth its own change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG