fix: task_state stuck-slot bug on init failure; vm_defuse leak; document api.Runtime.init() staleness invariant

Follow-up deep audit (3 parallel passes: narrow-int @intcast overflow,
the stale-setActive bug class elsewhere, leaks/stale-slices in this
session's own new code) after the ipv6InCidr and activate() bugs.

- task_state.zig claimSlot: slot.status was set to .ready BEFORE
  vs.create()/vs.init() ran. On failure (realistically OutOfMemory),
  the slot was left stuck .ready with vs == null -- permanently
  removed from the pool, since only .empty/.dead slots are reclaimed.
  Under sustained memory pressure with repeated spawn attempts, this
  could exhaust the task table and produce spurious TooManyTasks well
  before 64 live tasks exist. Fixed by only setting .ready after vs is
  fully initialized.

- vm_defuse.zig buildDefusedCode: `out` (up to chunk.MaxCode) leaked
  if decodeAt (Pass 2) or remapConstFuncIps (Pass 3) failed after the
  alloc succeeded -- reachable on every gbc_writer.write() call under
  memory pressure. Fixed with errdefer.

- api.Runtime.init() has the identical "returned by value, internal
  self-pointers go stale" shape as the activate() bug just fixed, but
  is currently safe because every real entry point (run, runPath,
  call, etc.) re-activates on its own final address before touching
  global state. Documented the invariant so a future method doesn't
  silently break it.

Verified clean under standard, -Dpreset=stress, and -Dgc_stress=true.

Author: ganehag

src/lang/task_state.zig

@@ -129,11 +129,22 @@ pub const State = struct {
             // shape; skip it on wraparound so idFor() never mints a
             // TaskId indistinguishable from the null ref.
             if (slot.generation == 0) slot.generation = 1;
-            slot.status = .ready;
+            // status is set to .ready only AFTER vs is fully created and
+            // initialized (not before, as this used to do): a failure in
+            // create()/init() (realistically OutOfMemory) must leave the
+            // slot .empty and reclaimable by a later claimSlot call, not
+            // stuck .ready with vs == null -- that used to permanently
+            // remove the slot from the pool for the rest of the process's
+            // life (an .empty/.dead check is all that lets a slot be
+            // reused; .ready never matches either). Under sustained memory
+            // pressure with repeated spawn attempts, this could exhaust
+            // the task table and produce spurious TooManyTasks well before
+            // 64 *live* tasks exist.
             const vs = try self.allocator.create(vm_state.State);
             errdefer self.allocator.destroy(vs);
             vs.* = .{};
             try vs.init(vm_state.MaxStack, vm_state.MaxFrames, cfg.max_defers, 0, self.allocator);
+            slot.status = .ready;
             slot.vs = vs;
             slot.owns_vs = true;
             return .{ .idx = idx, .id = self.idFor(idx) };

src/lang/vm_defuse.zig

@@ -593,6 +593,13 @@ pub fn buildDefusedCode(cs: *chunk.State, alloc: std.mem.Allocator) ![]u8 {
 
     // Pass 2: emit expanded instructions with corrected jump offsets.
     const out = try alloc.alloc(u8, new_len);
+    // decodeAt below (Pass 2) and remapConstFuncIps (Pass 3) can both still
+    // fail after this alloc succeeds -- without this, `out` (up to
+    // chunk.MaxCode) leaks on every such failure, reachable on every
+    // gbc_writer.write() call under memory pressure at these specific
+    // internal allocations. The function's own success path returns `out`
+    // itself (not freeing it), so this never fires there.
+    errdefer alloc.free(out);
     old_ip = 0;
     new_ip = 0;
     while (old_ip < old_len) {

src/runtime/api.zig

@@ -132,6 +132,22 @@ pub const Runtime = struct {
         };
     }
 
+    // Returns Runtime BY VALUE, copied at least twice more after
+    // initWithConfig runs (into `rt` below, then again into the caller's
+    // own storage on return) — inner.activate()'s process-global pointers
+    // captured during initWithConfig are stale by the time this function
+    // returns, exactly the bug class fixed 2026-08-20 in
+    // compiler_test.zig's manually-driven VMContext tests (see
+    // Runtime.activate()'s doc comment). Calling activate() again here
+    // would not help — it would just be stale again after the next copy.
+    // This is safe ONLY because every current entry point that touches
+    // vm/tasks_mod/fs_state/net_state/http_state (run, runPath,
+    // runPathWithSources, runPathWithSourceProvider, call, runIncremental,
+    // begin/continueRun) transitively calls self.inner.reset() or
+    // self.inner.activate() on ITS OWN final, stable `self` before doing
+    // anything else. Any NEW api.Runtime method that touches that state
+    // MUST do the same as its first action — do not assume init()'s work
+    // survives the return.
     pub fn init(config: Config) !Runtime {
         var inner: rt_mod.Runtime = undefined;
         try inner.initWithConfig(