[svozza]

Summary

The scripts under .github/scripts were CommonJS, pinned by a local package.json with "type": "commonjs", while the rest of the repo is ESM. This PR flips that directory to ESM and converts the two scripts and their call sites, so the directory has one module system and new scripts such as the workspace resolver in #5638 can be plain .js files.

Changes

• .github/scripts/package.json is deleted. It existed only to pin the directory to CommonJS after the root went ESM (chore: switch codebase to default esm #3959); with it gone the scripts inherit "type": "module" from the root package.json. File names are unchanged, so the fifteen prepack entries that run the release patch script are untouched.
• release_patch_package_json.js: require replaced with import; behaviour unchanged.
• report_e2e_sweep.js: formatReport is a named export and the reporter is the default export.
• The notify job in sweep-stale-e2e-stacks.yml: the actions/github-script step loads the module with await import() on a github.workspace path, the form documented in the action's README, since the snippet itself is evaluated as CommonJS.
• The job-summary step in sweep-stale-e2e-stacks.yml runs its node <<'NODE' heredoc with --input-type=module and a static import, because stdin scripts default to CommonJS.

Verified locally: the release patch script against a copy of a package manifest produces the same trimmed output; the github-script module imports by absolute path with the expected exports; the summary heredoc renders a report from the repo root; Biome and actionlint pass. Triggering the stale-stack sweep workflow manually after merge is the cheapest way to exercise the await import() form in a real run.

Rebased onto main after #5618 retired post_release.js and post-release.yml; the ESM conversion of those two files was dropped.

Issue number: closes #5639

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.