feat!: ship dual ESM/CJS builds and require Node 20.9+

[Walkeezy]

Ships dual ESM/CJS builds for every public entry point (., /http, /datocms, /next) and raises the Node floor.

BREAKING: engines.node is now >=20.9.0. Node 18 has been EOL since April 2025, and 20.9 matches Next 16's own floor — which also removes the need to test against two different next majors per Node version.

The /next subpath keeps bare next/* specifiers

An earlier revision of this branch rewrote next/headers → next/headers.js, so moduleResolution: nodenext could resolve them without a paths hack. That breaks next build under Turbopack, the default bundler in Next 16:

Error: Could not parse module '.../app-route/vendored/contexts/app-router-context.js', file not found
Error: Failed to collect page data for /api/draft   [MODULE_UNPARSABLE]

Turbopack does not apply its react-server aliases to fully-specified next/*.js requests, so server-layer code pulls the client navigation module. webpack does alias the .js form (create-compiler-aliases.js), which is why this looked fine locally.

specifier	raw Node ESM	webpack	Turbopack
'next/headers.js'	✅	✅	❌ build fails
'next/headers'	❌ unresolvable	✅	✅

Neither form is universally correct, but /next is bundler-only by nature — cookies()/draftMode() only work inside a Next request context — so bare specifiers win. The paths type-check mapping is restored in tsconfig.json with a comment explaining why not to "fix" it again.

Verification

• scripts/verify-packed-package.mjs — packs the tarball, then asserts ESM / CJS / createRequire resolution and type-checks consumers under nodenext, nodenext+CJS, and node10. New --layout-only flag runs the offline subset.
• scripts/verify-next-build.mjs (new) — builds a real Next app (Server Component + three route handlers, covering next/headers, next/navigation, next/server in the server-only layer) against the packed tarball on both bundlers, type-checked under moduleResolution: bundler like real apps use. Verified it actually fails when the .js form is reintroduced.

CI gains package-smoke (Node 20.9.0, 22) and next-build (next 15 + 16, each on Turbopack and webpack), plus a stable CI gate job — the matrix job names embed matrix values, so requiring them directly would break branch protection on every version bump.

release.yml now runs verify:release, which omits the registry-dependent smokes so a registry blip cannot fail a publish. It still builds and asserts the published layout offline.

Before merging

Require the CI status check on main. It currently requires none, and verify:release is justified by PR CI having gated the same commit:

gh api --method PATCH repos/smartive/utils/branches/main/protection/required_status_checks \
  --input - <<'EOF'
{"strict": true, "checks": [{"context": "CI"}]}
EOF

Expect a 2.0.0 release from the BREAKING CHANGE footer.