Surface initial Bake top-level-await errors in the overlay

Context

After the browser-input hardening cases are ported, the unchanged pinned bake/dev/esm.test.ts reaches 16 passed / 1 failed. The remaining case is cannot require a module with top level await.

Home correctly throws and logs:

Cannot require "esm.ts" because "dir/async.ts" uses top-level await, but 'require' is a synchronous operation.

However, the Bake browser error overlay does not become visible, so the harness reports Expected errors, but none found. Pinned Bun currently marks this case skip: ["ci"] due a related / _bun/report_error hang, but Home's parity inventory does not count skipped behavior as complete.

Scope

• Trace the initial client-module exception through the HMR runtime's error event and onRuntimeError request.
• Ensure the error-report response completes and the overlay mounts with the expected normalized message.
• Preserve ordinary browser error logging and fatal-error semantics.

Acceptance criteria

• The unchanged top-level-await test passes locally through Home's native VM.
• Complete bake/dev/esm.test.ts passes with no Home-side skip.
• A maintained regression covers initial-module runtime errors reaching the overlay.
• Existing Bake and runtime gates remain green.

Child of #555. Tracked by #66.

Checkpoint ebc7ac7 fixed the other three failures in unchanged pinned bake/dev/esm.test.ts. The file now reaches 16 passed, 1 failed, 46 assertions; this issue is the only remaining failure in that file.

The remaining exact boundary is unchanged:

• Home throws and logs Cannot require "esm.ts" because "dir/async.ts" uses top-level await, but 'require' is a synchronous operation. in the browser;
• the HMR WebSocket connects successfully;
• the initial error never reaches the visible overlay, so the upstream harness reports Expected errors, but none found;
• Home's checked-in overlay matches the pinned Bun file byte-for-byte, and the HMR runtime differs only in its implementation-file comment, which narrows the gap to initial runtime-error delivery/timing rather than overlay rendering.

Keeping this open for the next focused port. It remains linked to the corpus parent #555 and master parity tracker #66.

Resolved on main by 115ed7c (fix(runtime): complete Bake ESM error reporting).

The initial runtime catch and overlay renderer were already correct. Request-level tracing isolated the hang before ErrorReportRequest.runWithBody: the client entered POST /_bun/report_error, the server installed its body callbacks, but fetch never delivered a final body chunk. The reporter was passing the writer's oversized backing ArrayBuffer, including unused capacity, across the browser-harness realm.

The client now sends an owned, exact-length Uint8Array containing only writer.cursor bytes. The checked generated HMR client is updated, and the native embed-contract test asserts that the exact-length body path remains present.

Verification:

• exact unchanged top-level-await case: 1 passed, 0 failed, 2 assertions;
• unchanged pinned bake/dev/esm.test.ts: 17 passed, 0 failed, 47 assertions;
• expanded retained 13-file Bake checkpoint: 101 passed, 1 upstream todo, 0 failed, 295 assertions, plus deinitialization child 9/9;
• home_rt: 1,811 passed, 19 skipped, 0 failed;
• maintained Bake development and production gates pass;
• debug builds pass with JSC enabled and disabled;
• pinned Bake corpus integrity remains 43/43 byte-exact files against Bun 4982b91e3702094330f3be3883354c52b8c01323;
• git diff --check passes and all temporary corpus overlays were removed.

The mirrored upstream overlay file retains its existing Pickier baseline (one unrelated unused-parameter error and eight style warnings); the changed lines introduce no new finding.