Threads: async-generator handler unwind asserts stack depth under parallel_js (Linux CI)

[chrisbbreuer]

Parent: #502, #478

Evidence

Two consecutive CI runs panicked in `unit (shard 1/4)` on the same test, while the identical suite passes locally on macOS (6/6 single-test and full-shard runs):

• run 32613799527 (`e0aacfd4`) and run 32619584172 (`0abebd1a`): `parallel_js: evaluate roots async completion through Thread keepalive GC` → `thread panic: reached unreachable code`

Stack (both runs): `OperandStack.shrinkRetainingCapacity` assert `new_len <= items.len` fired from `execLoop`'s error-unwind path (`vm.zig:6026`) via `asyncDrive`/`runAsync` — i.e. an active `Handler` recorded a `stack_depth` greater than the live operand stack at throw time during async-generator resumption.

Analysis

• The failing test never configures `heap_limit_bytes`, so the Threads: fix failing corpus cases mc-lock-stop-vs-park and oom-one-thread #722 conservative-pin grace is inert here (`budget_allocator == null`); the commit pairing is

[chrisbbreuer]

CI recurrence on iterator-only descendant 9c682655f25f213e73f983c9c3cf2baa130869b8:

• run: https://github.com/zig-utils/zig-js/actions/runs/32812997510
• job: https://github.com/zig-utils/zig-js/actions/runs/32812997510/job/97695898752
• failing test: context.test.parallel_js: evaluate roots async completion through Thread keepalive GC
• assertion: vm.zig:218 in Stack.shrinkRetainingCapacity (new_len <= self.items.len), reached from execLoop -> asyncDrive -> runAsync
• preceding shard tests, including the strict iterator-record tests added for Iterator protocol: make GetIterator require and honor @@iterator #752, passed.

This is the same async handler/frame-unwind failure family. No async/jobs change is included in the iterator work.