Fix grounded follow-up audit findings

[0disoft]

Summary

This PR applies only the follow-up review findings that were supported by current code, tests, docs, or direct reproduction.

Implemented fixes:

• Defer runtime.close() when it is called from inside the currently running scoped task callback, so the callback can resolve and the scoped task can become terminal before JSON summary finalization.
• Timestamp task events at emission time so parent aggregate task events no longer reuse stale parent updatedAt values when child progress changes.
• Add the public task.skip(message?) API because TaskStatus, summary counts, and rendering already supported skipped, but callers had no handle method to produce it.
• Add a pull request and main push CI workflow that runs bun run check and bun run pack:check on Node 24.
• Split release publish and GitHub Release creation permissions so the npm publish job no longer has contents: write.

Tests added:

• Scoped close inside a task callback emits a final summary with running: 0 and succeeded: 1.
• Parent aggregate task event timestamps advance after child progress updates.
• task.skip() emits skipped task status and increments skipped summary count.

Local verification run in the analysis environment:

• npx tsc -p tsconfig.json --noEmit
• npx oxlint src test
• npx oxfmt --check .
• rm -rf dist-test dist && npx tsc -p tsconfig.test.json && node --test "dist-test/test/**/*.test.js"
• npx tsc -p tsconfig.build.json
• node test/fixtures/consumer-esm.mjs
• npx tsc -p test/fixtures/consumer-ts/tsconfig.json --noEmit
• npm pack --dry-run --json

Result: 98 Node tests passed locally. The local runtime was Node 22, while this package targets Node 24+, so the new CI workflow should be treated as the final Node 24 gate.

Deliberately not included

• Shared stream coordinator for concurrent live/plain runtimes: the issue is reproducible, but the correct fix is architectural. A partial change would either break the documented plain fallback contract or silently drop secondary runtime output.
• Bounded backpressure queues and dropped-frame diagnostics: the risk is real, but it changes buffering and event-loss policy. Existing tests intentionally preserve pending plain/json frames before timeout.
• Text byte caps for title/message/detail/log: the risk is valid for untrusted child process output, but default caps would be a public API policy change and need explicit option names and docs.
• Tombstone retention pruning: valid long-running memory concern, but it requires a handle lifecycle redesign rather than a safe localized patch.
• Pinning third-party GitHub Actions to commit SHAs: the release workflow still uses version tags. I only separated job permissions here because exact SHA pinning needs a repository-wide dependency update policy and should be done consistently for CI and release workflows together.
• stdout option removal/rename, attachLogStream, scaffold policy docs, and Node/npm fallback scripts: these are product/API/documentation tasks, not directly necessary to fix the reproduced failures in this PR.

[gemini-code-assist]

Code Review

This pull request introduces a new skip API to mark tasks as skipped (e.g., for cache hits) and updates the task event creation timestamp to use Date.now(). It also adds context tracking using AsyncLocalStorage to defer runtime closing when requested inside a scoped task callback. The review feedback highlights two critical issues: a potential memory leak where task handles are not disposed of if a scoped task callback throws an error, and a bug in #shouldDeferScopedClose where checking #handles.has(activeHandle) can prevent deferred closing if the handle was already manually disposed.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

When a scoped task callback throws an error, the catch block handles updating the task status in the store, but the task handle itself is never disposed. This leads to a memory leak because the handle remains in the #handles set indefinitely, and any registered AbortSignal listeners are not cleaned up.\n\nTo fix this, we should explicitly call handle.dispose() in the finally block of runtime.task. Since dispose() is idempotent, this is safe to call even if the task succeeded and was already disposed.

    } finally {\n      handle.dispose();\n      this.#activeScopedTasks -= 1;\n      await this.flush();\n      if (this.#shouldRunDeferredScopedClose()) {\n        this.#closeRequestedByScopedTask = false;\n        await this.close();\n      }\n    }

[gemini-code-assist]

The check this.#handles.has(activeHandle) in #shouldDeferScopedClose can cause unexpected behavior. If a scoped task manually disposes its handle (e.g., by calling handle.succeed() or handle.fail()) and then calls runtime.close() from within its callback, the handle is no longer in #handles. This causes #shouldDeferScopedClose to return false, meaning the close is not deferred and the runtime is closed immediately, potentially cutting off other active parent or concurrent tasks.\n\nSince activeHandle is retrieved from this.#taskCloseContext (which is an instance-specific AsyncLocalStorage), any returned handle is guaranteed to belong to this runtime. We can safely remove the #handles.has check to ensure that close() is always deferred when called from within any scoped task callback, regardless of whether the handle has been manually disposed.

  #shouldDeferScopedClose(): boolean {\n    return (\n      this.#taskCloseContext.getStore() !== undefined &&\n      this.#activeScopedTasks > 0 &&\n      !this.#closing &&\n      !this.#closed\n    );\n  }