Simplify browser builds and SPIR-V testing

[jph00]

The existing gpucpp link interface also forces --closure=1. Closure is not required by Emdawn or for correctness; it is only a size optimization. Emscripten’s bundled native Closure binary is x86-64, so Apple Silicon builds fall back to Closure’s Java implementation and gpu.cpp has to detect and configure OpenJDK. This makes every browser consumer pay for another toolchain component and slows the normal edit-link-test loop.

For gpu-browser-app, Closure reduced the combined compressed JS and Wasm artifacts from approximately 123 KB to 107 KB. That saving does not justify a second build path or a Java dependency. This PR therefore removes Closure entirely, together with the macOS Java detection and documentation. External browser consumers now inherit only the settings required for gpu.cpp to work, and development, testing, and release use the same linker path.

The integration also exposed a useful native testing boundary: downstream SPIR-V producers need to verify their generated module against gpu.cpp’s WebGPU-profile Dawn setup. The test runner now accepts ./test --spirv FILE, executes the supplied module, and checks the same known output as gpu.cpp’s assembled fixture.

CI now installs NumPy into an Actions-managed Python rather than the runner’s Homebrew Python, which rejects system-level package installation under PEP 668.

The essential design is that gpucpp supplies the WebGPU runtime requirements, applications own their Embind surface, and neither side needs Closure or Java.