fix(tests): bump fork heap via poolOptions.execArgv (NODE_OPTIONS ignored)

PR #198 added NODE_OPTIONS=--max-old-space-size=8192 to the
frontend-tests workflow assuming vitest's forks pool would inherit
it. It does NOT. Vitest 4's forks pool spawns workers via
child_process.fork() with an explicit execArgv list and ignores
the parent shell's NODE_OPTIONS env var — verified by reading the
post-merge GHA log: the Node OOM still fires at ~4.0 GB heap,
exactly the default v8 ceiling.

Set the heap cap at the pool level instead so the workers actually
see it. This is the canonical vitest 4 idiom for raising worker
limits — `poolOptions.forks.execArgv` is forwarded verbatim to
each forked child.

Independent of: the gpio_matrix_cb SIGSEGV fix in qemu-lcgamboa
(now landed) which addresses the Backend E2E failure mode. This
PR is exclusively the Frontend Tests heap fix.

This also serves as the trivial commit needed to re-trigger the
master CI run against the now-fixed libqemu binaries (v1.1.1
served from the license endpoint).

frontend/vitest.config.ts

@@ -26,6 +26,16 @@ export default defineConfig({
     poolOptions: {
       forks: {
         singleFork: false,
+        // Vitest 4's forks pool spawns workers with its own execArgv
+        // and does NOT inherit NODE_OPTIONS from the parent shell, so
+        // raising `--max-old-space-size` via the GHA env-var has no
+        // effect on the actual worker process. The full suite leaks
+        // ngspice WASM modules + singleton state across 117 files and
+        // hits Node's 4 GB default at the end of the run ("Worker
+        // exited unexpectedly / Ineffective mark-compacts near heap
+        // limit"). Bump to 8 GB at the pool level so it actually
+        // takes effect.
+        execArgv: ['--max-old-space-size=8192'],
       },
     },
     coverage: {