chore: replace tsx with plain Node

[Mrtenz]

Explanation

Modern versions of Node.js support running TypeScript files by default, so we can drop the tsx dependency.

This is in preparation for #9937, as tsx requests too many permissions by default.

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Wide CI and developer-tooling surface area depends on experimental Node TypeScript flags and the custom resolver; regressions would break lint, type generation, and workflows rather than shipped wallet logic.

Overview
Replaces tsx across the monorepo with Node.js running TypeScript directly, using --experimental-transform-types and a new scripts/resolver/register.ts hook so existing .js import paths and some package resolutions (e.g. @metamask/utils) still work at runtime.

Root and workspace package.json scripts for lint, messenger action types, changelog/codeowners helpers, and similar tooling now invoke node (with the resolver where needed). tsx is removed from devDependencies repo-wide, LavaMoat drops tsx>esbuild, and GitHub Actions call yarn scripts like get-changed-workspaces and close-stale-release-prs instead of yarn tsx scripts/....

messenger-cli and platform-api-docs tests were updated to spawn the CLI the same way CI does; bridge-controller / bridge-status-controller align on messenger-cli scripts (replacing the old generate-method-action-types entry), with a regenerated ordering tweak in bridge-status method action types.

^{Reviewed by Cursor Bugbot for commit 20ac37f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Mrtenz]

bridge-controller and bridge-status-controller didn't have a messenger-action-types:check or messenger-action-types:generate, allowing this file to become out-of-date.

[mcmire]

Still need to add this to yarn.config.cjs. I'll file a ticket.

[Mrtenz]

This is unfortunately needed for a few reasons:

1. Some of our scripts import from @metamask/utils, which resolves to @metamask/utils/dist/...js which doesn't exist in CI.
2. Some packages run an E2E-style test of a CLI (messenger-cli, platform-api-docs, wallet-cli) which references source files with .js imports.
3. Most packages run the messenger CLI to generate action types, referencing the source files with .js imports.

Part of this file should be temporary. Once we update packages to use .ts imports everywhere, we can drop the .js to .ts resolution. Unfortunately I'm not sure if we can get around the @metamask/utils resolution without replacing the functionality in the scripts.

[mcmire]

This seems okay for now. It's pretty small. I wonder if once we split up @metamask/utils into smaller packages we won't need to have separate exports (we'll just say, for instance, in order to use the @metamask/fs-utils package, you'll need to use Node).

[Mrtenz]

We need --experimental-transform-types because @metamask/utils uses enums. We can remove this if we replace the enums.

[mcmire]

This gives us time to migrate utils so I'm okay with it. It's good that once we don't need this we can quickly remove it via yarn.config.cjs too.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2f0ec41. Configure here.}

[mcmire]

LGTM.

[mcmire]

This seems okay for now. It's pretty small. I wonder if once we split up @metamask/utils into smaller packages we won't need to have separate exports (we'll just say, for instance, in order to use the @metamask/fs-utils package, you'll need to use Node).

[mcmire]

This gives us time to migrate utils so I'm okay with it. It's good that once we don't need this we can quickly remove it via yarn.config.cjs too.