Track multithreaded JavaScript support

[chrisbbreuer]

Goal

Track the work needed to make zig-js support multithreaded JavaScript faithfully, starting with isolated agents/workers and progressing toward shared memory and future shared-data proposals.

Background

Today, a Context is single-thread-affine: the interpreter, VM, global object graph, environments, microtask queue, and arena-backed allocation model assume one mutating thread. The first target should be isolated JavaScript agents rather than shared mutable ordinary objects.

The TC39 structs proposal is relevant future context: https://github.com/tc39/proposal-structs. It is currently Stage 2 and proposes fixed-layout structs, shared structs, and synchronization primitives such as Atomics.Mutex and Atomics.Condition. Shared structs should come after the baseline worker, structured clone, SharedArrayBuffer, and Atomics stack is correct.

Milestones

• Make Context thread-affinity explicit and reject accidental cross-thread use.
• Document which Zig and C API handles are local to an agent.
• Add worker agents: one Context per OS thread with its own global object, realms, queues, allocator state, and module loader hooks.
• Implement structured clone for message passing.
• Implement ArrayBuffer transfer and detach semantics.
• Add worker lifecycle, cancellation, and host scheduling hooks.
• Finish SharedArrayBuffer behavior across agents.
• Finish typed-array views over shared storage.
• Implement Atomics, including Atomics.wait / Atomics.notify behavior.
• Support the real test262 $262.agent harness.
• Replace or contain arena-backed allocation before cross-agent lifetimes can leak.
• Define future GC rooting, write-barrier, and cross-agent ownership rules.
• Separate per-agent microtask queues from host task queues.
• Add stress tests for transfer/detach races, shared typed-array atomics, worker teardown, and host callback reentrancy.
• Track TC39 proposal-structs and evaluate shared structs once the baseline shared-memory stack is correct.

Verification target

This issue is done when the relevant Test262 worker/shared-memory coverage can run under the upstream harness without host failures, and multithreaded behavior has dedicated stress coverage in this repo.