test(core): run Code Mode's executor on plain workerd, and check what core keeps after many runs

[nickruigrok]

Fifth and last PR of the GRA-349 stack, on top of #390. It runs Code Mode's executor on plain workerd (decision D2) and checks what core keeps after many runs.

Retention: what is measured, and what can't be

• Not measured: what the runtime holds for a run (its isolate, and the RPC sessions of its stubs). workerd offers no signal to read:
  • I counted sessions of the seven code APIs by incrementing a counter in their constructors and decrementing it in [Symbol.dispose]. After 30 calls the counter read 30 opened and 30 still open, and was unchanged 3 s later. The runtime never calls [Symbol.dispose] on these loopback entrypoints.
  • Worker Loader exposes no count of loaded isolates.
  • The stubs core passes have no Symbol.dispose to call.
  • So this PR doesn't claim measured handle retention. The earlier HeldHandles registry is removed: it counted core's own bookkeeping and disposed nothing.
• Measured: core's own state. After 40 runs over 4 turns (20 completed, 10 threw, 10 failed to load; 30 of them calling an API), Workspace.codeRunRetention() reads 0 open leases and 0 outputs held, with 40 closed leases (bounded by endedRunsKept). The run records hold 20 completed, 10 threw and 10 load_failed.

Plain workerd (D2)

• vp run smoke:code-mode (scripts/workerd-code-mode.ts) bundles the same runCode core runs into a small Worker (apps/core/test/workerd/code-mode-worker.ts).
  • It bundles with Wrangler's dry run, as smoke:workerd does, so a frozen install is all it needs.
  • It serves the Worker with workerd serve --experimental and a workerLoader binding, with no Miniflare.
  • It retries only a refused connection, within an overall 120 s timeout.
• These 12 cases end as they do in core:

Case	Ends as
complete module (helpers, self === null, ctx with only waitUntil, two parallel capability calls)	completed, exactly 2 calls taken
fetch	threw
syntax error, non-function export, module that throws while loading (its log kept)	load_failed
function that throws	threw
module over 200,000 characters	refused
promise that never settles	wall_expired
60 s wait under a 1 s limit	wall_expired, within 5 s
cancelled after 300 ms	cancelled
5,000 one-line logs	completed, exactly 1,000 lines streamed
flood of output	threw, at most 64 KiB, cut with the marker, lines streamed (no more than 1,000), its error ending kept

• The runtime reports {"runtime":"workerd","cpuLimit":"cpu_limit_unsupported"}.
• CI runs it in the workerd job, right after smoke:workerd.
• From a fresh frozen install: I made a new worktree, ran vp install --frozen-lockfile (which leaves no esbuild in the root .bin), then vp run smoke:code-mode. It passed all 11 cases (the line-cap case came after).

Finding for GRA-382 and the on-prem profile. On plain workerd (1.20260921.1), a synchronous busy loop in a loaded Worker holds the thread the host's wall-clock timer needs, so the host never lets go. Until the CPU limit is proven on the deployed profile, on-prem must not offer Code Mode.

Evidence (top of the stack)

• vp check: passes.
• Core: 230 passed.
• Screen-config tests: 47 passed.
• Web: 12 passed.
• smoke:code-mode: passes, 12 cases (c2a75f3), and 11 cases from a fresh frozen install.
• check:migrations: passes.

[nickruigrok]

@greptileai review

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no new actionable issues were found.

Summary

Adds a plain-workerd smoke test for Code Mode and checks the state core keeps after repeated runs.

• Code Mode’s executor runs through a smoke check on plain workerd.
• Core can report how many code-run leases and outputs it keeps.

_{Reviews (2) · Last reviewed commit: "test(core): check the closed-lease cap, ..." · Reviewed by Greptile}

[nickruigrok]

@greptileai review