Build standalone binaries for macOS and Windows in release CI

[SVAGEN26]

This is a Claude Code agent acting on behalf of @JKRT.

Summary

Addresses AnHeuermann's review comment on OpenModelica/OpenModelica#15925 asking for a real release of modelica-language-server so OMEdit's CMake bundling can download platform-specific binaries instead of relying on a local build.

Today .github/workflows/test.yml only builds and releases a single Linux x64 binary (modelica-language-server-linux-x64). This adds a build-binaries matrix job (gated to tag pushes, same as release) that builds the Node.js SEA standalone binary on:

• macos-latest (arm64) → modelica-language-server-macos-arm64
• macos-13 (x64) → modelica-language-server-macos-x64
• windows-latest (x64) → modelica-language-server-windows-x64.exe

Each is uploaded as a build artifact and then attached to the GitHub release alongside the existing Linux binary, .vsix, npm tarball, and WASM files.

Note: the SEA binary embeds the actual node executable it was built with (see server/scripts/build-standalone.js), so it is not portable across OS/arch — hence the per-platform matrix rather than a single universal binary. macOS builds also strip and ad-hoc re-sign the code signature, which the existing build script already handles.

Test plan

• Validated the updated workflow YAML parses correctly.
• CI run on this PR (build/test job, no release since it's not a tag push).
• On next version tag, confirm build-binaries runs and all four platform binaries attach to the GitHub release.

[SVAGEN26]

Addressed in 9971c77: dropped the if: startsWith(github.ref, 'refs/tags/') gate on the build-binaries job so the macOS/Windows standalone binaries build on every push to main and every pull request. The release job remains tag-gated, so publishing behaviour is unchanged. First CI run against the change should confirm the matrix stays green outside a release.

[SVAGEN26]

As predicted — dropping the tag gate immediately caught a real Windows build failure: spawnSync ...\node_modules\.bin\postject ENOENT. On Windows npm installs postject.cmd in .bin, not a bare postject file, so execFileSync of the bare name could not find it — this only ever surfaces on Windows and would have first appeared at release time under the old gating.

Fixed in 746c224 by resolving postject's JS entry via require.resolve('postject/dist/cli.js') and invoking node on it directly, bypassing the .bin shim (which is where the .cmd/.exe/no-extension platform variance lives). Verified locally on Linux: SEA build produces a 95 MB standalone binary that starts up (the LSP correctly refuses to run without --stdio, as expected). Fresh CI run is queued at head 746c224 — the Windows matrix job is the one to watch.