Add standalone binary build via Node.js SEA

[SVAGEN26]

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

Summary

• Adds `npm run build:standalone` in `server/` producing a self-contained `modelica-language-server[.exe]` via the Node.js Single Executable Application (SEA) API (Node >= 20).
• Adds `server/sea-config.json` consumed by the SEA build step.
• Adds `server/scripts/build-standalone.js` — cross-platform build script (handles macOS codesign removal and ad-hoc re-signing automatically).
• Adds `postject` as a dev dependency (injects the SEA blob into the node binary copy).

Why

Some editors and IDE integrations bundle language servers so that users do not need to install Node.js separately. A pre-built standalone binary makes the server usable out of the box in those contexts without any runtime requirement on the end user's machine.

The two WASM files (`tree-sitter-modelica.wasm`, `web-tree-sitter.wasm`) must remain alongside the binary at runtime.

Suggested CI use

Platform-specific binaries can be built and attached to releases via CI:

```yaml

• run: cd server && npm ci && npm run build:standalone
• uses: actions/upload-artifact@v4
  with:
  name: modelica-language-server-${{ runner.os }}
  path: |
  server/out/modelica-language-server*
  server/out/tree-sitter-modelica.wasm
  server/out/web-tree-sitter.wasm
  ```

Test plan

• `cd server && npm ci && npm run build:standalone` succeeds on Linux, macOS, and Windows
• The produced binary responds correctly to an LSP `initialize` message when invoked with `--stdio`
• WASM files alongside the binary; tree-sitter parses `.mo` files correctly

[JKRT]

@AnHeuermann Just checking if you are OK with this change. The point of this PR being that one should be able to compile the language server as a stand alone thing

[AnHeuermann]

Sure. Add it to a workflow and save the WASM file on release.

[SVAGEN26]

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

@AnHeuermann this is updated per your review:

• The standalone binary build now lives in test.yml (the separate standalone.yml was removed).
• It is built in the existing build job on every run (npm run build:standalone), so the script is always exercised.
• The release job attaches the binary plus the WASM files to the generated release.

Locally npm ci && npm run build:standalone succeeds and the produced binary answers an LSP initialize over --stdio. The CI run is currently in action_required because this is a fork PR; could you approve the workflow run so the standalone step is validated on CI? Then it should be good to merge.