feat(worker_threads): worker.stdin Writable (parent→worker process.stdin bridge) (#1076)

[nickna]

Closes #1076. Follow-up to #1003, closing the last stdio gap of epic #996.

What

With stdin: true, worker.stdin is now a Writable on the parent whose writes are bridged into the worker's process.stdin Readable — the parent→worker mirror of #1003's worker→parent stdout/stderr. worker.stdin.write(chunk) surfaces as 'data' inside the worker; worker.stdin.end() surfaces as 'end'.

The wrinkle (and a latent bug fixed)

The worker's process.stdin resolved to the process-global SharpTSStdin.Instance, which spawns a background thread reading the real Console.In — so a worker would consume the host terminal.

Fix: a [ThreadStatic] WorkerThreads.WorkerStdin (mirroring the existing ClusterContext pattern), installed on the worker's dedicated thread in RunWorkerScript and consulted by ProcessBuiltIns.GetOwnMember("stdin"). It is always isolated to a per-worker SharpTSReadable (even without stdin: true) so a worker never touches the terminal, and is only fed from the parent when stdin: true is passed.

Bridge

• Parent-side worker.stdin is a SharpTSWritable created only on stdin: true (else GetMember returns null → reads as undefined, consistent with worker.stdout/stderr).
• Its write/final callbacks (mirroring the child_process stdin bridge) enqueue chunks / a null-EOF sentinel onto a dedicated BlockingCollection.
• The existing WorkerMessageHandler poll timer drains it each tick via new PumpStdin → PushFromHost into the worker's process.stdin (null ⇒ 'end'). No new cross-thread marshaling primitive; same lifecycle/guards as the message queue.

A dedicated queue (not the shared ClonedMessage record) is used because stdin and postMessage are separate channels in Node.

Scope note

A worker started without stdin: true gets an isolated stdin that stays open (never emits 'end') rather than ending immediately as Node does — strictly better than the prior behavior and not worth the edge-case complexity here.

Tests (dual-mode)

• worker.stdin.write(...) → readable in the worker via process.stdin 'data'; end() → 'end'.
• Multiple writes preserve order (accumulate + flush on 'end').
• Un-piped worker.stdin is absent (falsy).

Verification

• Full xUnit: 15421 / 0 (incl. 123 WorkerThreadsTests)
• Test262 (interp + compiled): 22 / 0 / 4 skip (baseline)
• TypeScript conformance: 31 / 0
• Build clean (pre-existing warnings only)