Closes the emit_chunk item from the sync-NAPI deadlock audit in #7311.

Symptom

Plugins that call this.emitFile({ type: 'chunk', ... }) from a transform (or any hook, really) hang rolldown indefinitely once enough emits accumulate. The hang is deterministic for tight emit loops (~1025 emits from a single hook) and
non-deterministic under parallelism — it can trigger with as few as ~400 emits spread across concurrent transforms. There is no error, no log, no stack trace from rolldown — the build just stops making progress. The main JS thread ends up
parked inside _pthread_cond_wait under napi_call_function → ... → block_on, and every tokio worker is parked at the same pthread_cond_wait.

This was reproducible against rolldown@1.0.0-rc.13 on a real RSC plugin (@lazarv/react-server) building a Mantine-sized app (~3300 "use client" modules, each emitted as an entry chunk), and then
minimised to 30 lines of plugin code.

Root cause

PluginContext.emitFile({ type: 'chunk' }) is a sync napi binding. Until this PR it called napi::bindgen_prelude::block_on(...) on the JS thread to drive an async fn emit_chunk whose two await points were:

1. self.tx.lock().await on a tokio::sync::Mutex<Option<Sender<ModuleLoaderMsg>>>
2. send(AddEntryModule(...)).await on a bounded mpsc::channel(1024) shared with the module loader

The bounded channel is the trap. Once it fills, the send future can only be unblocked by the module loader draining it. But draining each AddEntryModule message dispatches plugin hooks (resolveId, load, further transforms) back to
the JS thread via TSFN — and the JS thread is pinned inside block_on servicing the current emit_chunk. The only consumer that can free capacity is waiting on the only thread that is blocked producing. Classic producer ⇄ consumer deadlock
through TSFN.

A couple of subtleties worth calling out, because they explain why the bug was easy to miss:

• The effective capacity is much lower than 1024. Under parallelism, in-flight module tasks spawned for earlier emits are already waiting on TSFN responses from the blocked JS thread. Those pending tasks keep the loader effectively frozen
  while the channel stays saturated, so the producer hits tx.send().await and hangs at a much smaller emit count. In local testing against unpatched rc.13:
  • 200 parallel inputs × 1 emit each → ✓ 62 ms
  • 500 → ✓ 154 ms
  • 600 → hang (after ~400 transforms processed)
  • 2000 → hang (never even reaches buildStart)
• Parallel transforms without emitFile scale fine. A control experiment — 12 000 virtual inputs each going through a transform hook that does not call emitFile — completes cleanly. So the bottleneck is not transform dispatch, TSFN
  throughput, fetch_modules, or the loader loop. It is specifically emit_chunk's block_on + bounded-channel interaction, exactly as audit: Review sync NAPI bindings for deadlock safety #7311 predicted when it flagged emit_chunk as MEDIUM risk.
• Yielding inside the JS transform does not help. setImmediate / process.nextTick / Promise.resolve yields let libuv service TSFN callbacks, but at the point the producer is stuck in block_on the consumer cannot hand the JS thread
  anything to do — the loader is either blocked on the current transform's TSFN response, or has no work ready that does not depend on the blocked thread. The deadlock is structural, not a scheduling race.
• This is not an "insanely large build" problem. Each "use client" file in a normal RSC project emits exactly one chunk from its own transform. 3300 client components is a reasonable size for an app. No plugin is doing anything
  pathological; the rolldown primitive simply does not survive its documented usage at scale.

Fix

Collapse the entire emit_chunk path to synchronous code and drop block_on from the napi binding. There is no reason any of it was async:

• FileEmitter::emit_chunk is now a sync fn. Its tx is a std::sync::Mutex<Option<UnboundedSender<ModuleLoaderMsg>>>. The critical section is Option::clone() — the Sender is cheaply cloneable — then the lock is dropped before send.
  The install/clear path runs only at scan boundaries and is never contended with build traffic; the per-emit path's contention is bounded to nanoseconds (lock-free CAS on the clone).
• BindingPluginContext::emit_chunk no longer enters the tokio runtime. It is now a plain sync binding with the same shape as the adjacent emit_file, marked // SYNC-SAFE per the convention introduced by fix(dev): make register_modules async #7289 / audit: Review sync NAPI bindings for deadlock safety #7311.
• PluginContext::emit_chunk and NativePluginContextImpl::emit_chunk are de-async'd to match.
• PluginDriver.tx is unified on std::sync::Mutex for consistency with FileEmitter.tx — the load hook holds it only to clone the sender and drop the lock before awaiting module-load completion.
• As defense in depth, the module loader's message channel is switched to unbounded_channel(). UnboundedSender::send is synchronous and infallible, so even if a future refactor reintroduces a sync wait on this path, there is no .await
  that can park the JS thread. All tx.send(...).await call sites in module_task.rs, external_module_task.rs, runtime_module_task.rs, and native_plugin_context.rs::load are updated accordingly.

JS API impact

None. this.emitFile({ type: 'chunk' }) remains synchronous and returns string directly, matching Rollup's PluginContext.emitFile contract. No plugin needs to change.

Tests

Two new deterministic regression fixtures under packages/rolldown/tests/fixtures/plugin/context/:

• emit-chunk-many-from-transform — a single transform hook emits 2000 chunks in a tight loop. Exercises the "tight emit loop" path. Deadlocks on main, passes in ~470 ms with this fix.
• emit-chunk-many-parallel-inputs — 1500 virtual inputs, each with its own transform emitting exactly one chunk. Exercises the realistic "large plugin at scale" path. Deadlocks on main, passes in ~600 ms with this fix.

Both are marked sequential: true and live alongside the existing plugin/context/emit-file fixtures. Full fixture.test.ts run is green (99/99).

Relation to #7311

#7311 audited sync NAPI bindings after the dev-engine deadlock fixed in #7289. It explicitly flagged emit_chunk as a MEDIUM-risk sync binding with deadlock potential, listed two possible resolutions (Option A: make async; Option B: add
SYNC-SAFE comment with justification), and left the task unchecked when the issue was closed as completed. This PR resolves that task by taking a third path: make the entire underlying implementation synchronous so the binding can stay
sync without block_on. The SYNC-SAFE comment is added per convention. This avoids the breaking-change implications of making this.emitFile return a Promise.