feat(worker_threads): compiled main-thread receiveMessageOnPort drain + MessageChannel messageerror (#1077)

[nickna]

Closes #1077.

Fixes the two compiled-mode gaps documented during epic #996 for the main-thread MessageChannel/$MessagePort path. The worker-driven paths were already dual-mode; this brings the interpreter-only MessageChannel cases to parity.

1. Synchronous receiveMessageOnPort (from #1000)

$Runtime.WorkerThreadsReceiveMessageOnPort was an unconditional undefined stub: $MessagePort is emitted by EmitMessageChannelTypes after EmitRuntimeClass, so the helper couldn't reference the port's _pending queue at emit time.

Fix: the method is still defined during EmitWorkerThreadsModuleHelpers (so call sites bind the token), but its body is now emitted afterward by a new EmitWorkerThreadsReceiveMessageOnPortBody, wired in right after EmitMessageChannelTypes and before EmitRuntimeClassFinalize (which closes $Runtime). The body synchronously dequeues one message from the port's own _pending queue and returns { message } (a Dictionary<string, object?>), else undefined — matching SharpTSMessagePort.ReceiveMessageSync.

2. messageerror on postMessage of an uncloneable value (from #1001)

The emitted structured clone (cloneCore) returns uncloneable values by reference and never throws, so a compiled $MessagePort had no clone-failure point and always delivered message.

Fix (confined to $MessagePort, per the issue's second option): PostMessage detects the uncloneable categories up front (typeof "function" — covers functions/classes/bound-callable wrappers/delegates — and "symbol") and enqueues a shared static _cloneError sentinel instead of a clone. Drain compares by reference and emits 'messageerror' (no args) instead of 'message'. This mirrors the interpreter's receiver-side model (ClonedMessage(IsError: true)) without touching the shared cloneCore, so compiled structuredClone / $BroadcastChannel are unaffected.

Notes

• Both paths stay fully standalone — pure emitted IL, no SharpTS.dll dependency; verified with --compile --verify and --compile --standalone --verify (both clean, no SharpTS.dll co-located).
• Deeply nested uncloneables (e.g. { fn: () => {} }) remain aliased, consistent with the emitted clone's existing shallow fallback — documented inline.
• Observed (pre-existing, out of scope): a compiled $MessagePort Refs the event loop on Start() unconditionally, unlike the interpreter which only Refs cross-thread ports. The existing compiled MessageChannel tests already work around this by closing ports; the new messageerror test follows that convention.

Tests

• ReceiveMessageOnPort_QueuedMessage_ReturnsMessageThenUndefined — new, dual-mode ({ message } then undefined).
• MessageChannelPort_PostUncloneable_FiresMessageError — was an interpreter-only [Fact], now a dual-mode [Theory].

Green: xUnit 15428/0 · Test262 22/0/4skip (interp + compiled) · TSConf 31/0.

[nickna]

Filed the two pre-existing divergences surfaced during this work as follow-ups:

• Compiled $MessagePort.Start() unconditionally Refs the event loop → started main-thread MessageChannel port hangs the process (dual-mode divergence) #1254 — compiled $MessagePort.Start() unconditionally Refs the event loop (started main-thread port hangs unless closed).
• Compiled structured clone (cloneCore) is shallow: aliases Date/RegExp/TypedArray/etc. and never throws DataCloneError on uncloneable values (dual-mode divergence) #1255 — compiled structured clone (cloneCore) is shallow: aliases Date/RegExp/TypedArray/etc. and never throws DataCloneError on uncloneable values (this PR only works around the top-level $MessagePort.postMessage case).

Both are out of scope for #1077 and left as-is here.