Re-enable sointu tests by moving compilation to client-side wasm

[petersalomonsen]

Background

The 3 tests in editorcontroller.spec.js's editorcontroller with sointu source suite depend on a remote compilation service:

• https://sointu-server-c6w7hd53ia-uc.a.run.app/process — called from getSointuWasm which the editor's compileSong path hits whenever songmode == SONG_MODE_SOINTU (editorcontroller.js:401-402).

The service is currently returning 503 Service Unavailable consistently, which makes:

1. The compileSong call throw before posting the audio worklet message → first sointu test only passes by luck (intermediate worklet messages arrive before the throw).
2. The "export to sointu yaml" and "export to wasm with lib functions exported" tests time out, because getSointuWasm is called even when the user requested only YAML export — and the YAML download path is gated on a successful synthwasm.

The suite was skipped via xdescribe in PR #119 to unblock CI — see commit context in editorcontroller.spec.js:193-198.

Proposed fix

Replace the cloud sointu compiler with a client-side WebAssembly build of sointu so:

• No external service dependency (CI no longer flakes on uptime / 503s).
• Faster export (no round-trip).
• Works offline.

Sointu is written in Go; one option is tinygo → .wasm. Another is Rust port. Either way, ship the wasm bundle alongside the existing wasm-lib/ and call it from playsointu.js instead of fetch(...).

Acceptance criteria

• getSointuWasm(song) runs entirely in the browser (no fetch to sointu-server-*.run.app).
• The 3 skipped tests in editorcontroller with sointu source are re-enabled (xdescribe → describe) and pass in both Chromium and Firefox under web-test-runner.
• YAML export does not depend on a successful wasm compile (decouple the if (synthwasm) gate around triggerDownload(... yaml ...) in editorcontroller.js:412-414).

Related

• Original PR that surfaced this: Store git repos in NEAR smart contracts via service worker #119