CI matrix fails on current master with no code change — cp38 EOL, cbor2 source-build breaks under QEMU

[sspickle]

Discovered by accident: a fork ran this repo's Test/build workflow against the current master tip (b2ddae8, the jupyterlab4 merge) and the matrix failed — and since this repo has no CI run for that commit at all, whoever pushes to master next will hit the same failures and reasonably assume their change caused them.

Run: https://github.com/sspickle/vpython-jupyter/actions/runs/31761503561 (the fork; code byte-identical to master here)

What fails, on an untouched master

leg	result	cause
build_aarch64 (cp38)	❌	Python 3.8 is EOL; leg fails outright
build_aarch64 (cp311, cp312)	❌	cbor2 builds from source under QEMU and its native build fails — no aarch64 wheel for the pinned combination, so every emulated leg pays a from-source build that no longer works
build (3.12, macos-latest)	❌	not yet diagnosed
build (3.11, ubuntu/macos), build (3.8, windows), cp310 aarch64	✅

Suggested triage, cheapest first

1. Drop cp38 from the matrix (Python 3.8 has been EOL since late 2024).
2. Get cbor2 as a wheel on the aarch64 legs — bump to a version shipping aarch64 wheels, or pre-install a binary in the cibuildwheel environment — rather than paying (and now failing) a QEMU-emulated source build per leg.
3. Diagnose the macos 3.12 leg once the noise above is gone.

None of this blocks development — the ubuntu 3.11 leg still passes, so tests run — but a red matrix on every future push makes CI useless as a signal, and there is Pyodide/packaging work heading toward this repo soon that will want a trustworthy build.