Go GOOS=js wasm: runtime init panics on incomplete node shims (process/path/fs.constants)

[e-fu]

After #17 (live mem.buffer aliasing + TextDecoder DataView support), a Go
GOOS=js GOARCH=wasm module boots through syscall/js and reaches its program
init, but then panics:

panic: syscall/js: call of Value.Get on undefined
goroutine 1 [running]:
syscall/js.Value.Get(...)

Instrumenting syscall/js.valueGet shows the property-access sequence right
before the panic:

Object, Array, process, path, fs, constants, Uint8Array

i.e. Go's runtime/os init reads globalThis.process, globalThis.path,
globalThis.fs, then fs.constants — one of these (or a member such as
fs.constants) is undefined, so the next .Get panics.

This is node-shim completeness, not the WASM runtime — the live-memory and
TextDecoder fixes in #17 are what get execution this far. To run Go modules,
QuickBEAM's node API surface needs the globals/members Go's wasm_exec.js
expects (process, path, a fs exposing constants, …), or
wasm_exec.js's own fallback shims need to be reachable.

A 12 MB Go signer module reproduces it. Filed from the work fork
ZenHive/quickbeam; the two
upstream-relevant runtime fixes are in #17.