Problem

Worker threads run a bare CFRunLoopRun() with no autorelease pool management. Autoreleased ObjC objects created while executing JS on a worker (marshalled method returns, framework-internal temporaries, call-scoped block copies) accumulate in the thread's implicit bottom pool and only drain when the worker dies — the backing NSOperation's pool is the only drain point. That is a memory leak proportional to worker lifetime and native-call volume. The main thread does not have this problem because UIKit installs run-loop observers that drain a pool once per loop pass.

Fix

Scope pools to the runtime's own callouts instead of to run-loop passes:

• EventLoop's RunGuarded wraps each non-bare work unit in @autoreleasepool — this covers both scheduler lanes (timers/setTimeout, posted internal work, V8 platform tasks), which is where worker JS executes. Bare entries stay unwrapped: they may @throw on purpose, and an ObjC unwind must not cross a pool this code owns. On the main thread this only tightens drain latency (callout-end instead of UIKit's pass-end); the lifetime contract — an autoreleased object lives at least to the end of the current callout — is unchanged on both threads.
• The worker's message-drain source callout wraps DrainPendingTasks() in @autoreleasepool.
• An explicit @autoreleasepool around the worker boot phase (isolate creation + entry-script evaluation + first message drain), which runs before CFRunLoopRun().
• An explicit @autoreleasepool around worker teardown (DestroyInspector() + delete runtime), so teardown garbage dies deterministically instead of whenever the operation's pool drains.

Why not a UIKit-style run-loop observer?

Two observer designs (single pool with drain-per-pass; one pool per run-loop nesting level, UIKit's scheme) were tried first and both abort with AutoreleasePoolPage::badPop under the HTTP-ESM loader tests: worker module loading pumps nested CFRunLoopRunInMode from inside callouts whose async machinery interleaves its own pool lifetimes across callouts, so an observer-owned token can be cut out from under the observer by a pool it does not control. A pool that is pushed and popped strictly inside a single callout cannot be interleaved with by construction — and per-callout @autoreleasepool at entry points is already this codebase's established pattern (ModuleInternalCallbacks, InteropTypes, AnimationFrame, HttpLoader).

Known limitation: callouts the runtime does not own (e.g. a notification block delivered directly to the worker loop) still autorelease into the bottom pool. All JS execution and marshalling paths are covered.

Test

TestRunner/app/tests/WorkerAutoreleasePoolTests.js + autoreleasePoolDrainWorker.js: the worker autoreleases a TNSAllocLog instance (new +autoreleaseInstance fixture method — CFAutorelease(CFBridgingRetain(...)), so the pool holds the only reference and no JS wrapper retain is involved) inside one timer callout and reports TNSGetOutput() from the next. The dealloc log can only be present in between if the pool drained between the callouts; without the fix it appears only at worker death, after the report is sent.

Full suite: green (Debug, simulator).