Bump babel dependencies, use caret range for all (v7)

[NullVoxPopuli]

bump minimum versions for babel deps -- ensure caret range is used for @babel/runtime

[NullVoxPopuli]

Note

I am a bot (Claude Code), commenting on behalf of @NullVoxPopuli.

Why CI is failing, and the prior art on this problem

All failing Acceptance / Floating-dependencies jobs die on the same boot-time error before any test runs:

Uncaught Error: Could not find module `@babel/runtime/helpers/esm/toPropertyKey.js`
imported from `@babel/runtime/helpers/esm/defineProperty`

Mechanism

When includeExternalHelpers is enabled, treeForAddon funnels @babel/runtime/helpers/esm/* into the app and transpiles it to AMD, registering extensionless module names (@babel/runtime/helpers/esm/toPropertyKey). Since @babel/runtime 7.13, the published ESM helpers import each other with explicit .js extensions (import toPropertyKey from "./toPropertyKey.js"). amd-name-resolver preserves the extension, so the AMD dep becomes ...toPropertyKey.js, which is not a registered module name → the loader throws, vendor.js fails to boot, and every browser test fails.

Version survey of @babel/runtime (checked the published helper files)

Versions	Cross-helper import style	Works with this setup?
≤ 7.12.18 (current pin)	import x from "@babel/runtime/helpers/esm/x" (extensionless)	✅
7.13.0 – 7.13.9	export { default } from "../x/index.mjs" (reverted upstream in babel/babel#12919)	❌
7.13.10 – 7.29.7 (current)	import x from "./x.js"	❌

So there is no newer @babel/runtime that avoids this — the fix has to be on ember-cli-babel's side.

Prior issues / PRs discussing this

• [v7.21.0] includeExternalHelpers option breaking with latest @babel #384 (2021) — original report: "includeExternalHelpers option breaking with latest @babel". @rwjblue's diagnosis: "Basically babel is including the extension in the import paths for the helpers, and our transpilation doesn't support modules at runtime including the extension."
• Update babel plugins and pin to @babel/runtime@7.12.8 #385 — the PR that introduced the 7.12.x pin as the mitigation.
• unpin @babel/runtime to see what tests fail #451 — "unpin @babel/runtime to see what tests fail" (still open, stalled).
• Private property transpilation broken w/ externalHelpers enabled #442 — related externalHelpers breakage; contains @ef4's recommended user-side workaround (stop using includeExternalHelpers, depend on @babel/runtime directly).
• Could not find module '@babel/runtime/helpers/esm/regeneratorRuntime' in a fresh new app #445 — same error class (regeneratorRuntime) reported in a fresh app.
• Does @babel/runtime still need pin? #519 (2025) — "Does @babel/runtime still need pin?" @gorner hit the identical toPropertyKey.js error trying ^7.26.10 and drafted a loader.js-side fix (ember-cli/loader.js#227); @ef4 declined changing loader.js/ember-cli-babel behavior broadly, as both are stable legacy code.
• Upgrade babel deps #530 — prior attempt at this same dependency bump. @ef4 relayed the tooling-team position that "a more targeted fix is possible" in the treeForAddon helpers funnel (index.js#L271): "We can patch/adjust babel/runtime so that the imports and the defines line up correctly."

Path forward for this PR

Following ef4's suggestion in #530: strip the .js extension from relative imports while transpiling the helpers tree (a small babel plugin added only to that one transpileTree call in treeForAddon). This is scoped entirely to the helpers funnel — no changes to loader.js or to general app transpilation. A patch implementing this passes ember test (including the external-helpers acceptance test) and the mocha node-tests locally with @babel/runtime@7.29.7; it will be pushed to this PR shortly.