refactor: drop CJS shim and ship handler.mjs as sole entry point

After feedback from Darcy Rayner (original handler.cjs/mjs author) and
re-evaluating the cold-start trade-offs, the shim is the wrong shape.

The shim's CJS branch saved ~10-30ms of cold-start init for CJS users
on the npm-redirect path, but its ESM branch moved 300-800ms of
tracer/handler load work from Lambda's init phase into the first
invocation. That's worse in three ways for ESM users (the cohort this
PR exists to fix):

  1. First-invoke timeout risk on functions with tight timeouts —
     the loading work now eats into the invocation's time budget.
  2. Provisioned concurrency is wasted — work deferred past init isn't
     pre-warmed, so PC customers pay for warm capacity and still hit
     cold-start latency on the first real request.
  3. Lambda SnapStart is wasted for the same reason — snapshot is
     taken after init, and the shim's lazy `import()` runs post-snapshot.

handler.mjs's async `load()` already handles both CJS and ESM user
modules transparently. Lambda's bootstrap resolves `dist/handler.handler`
to handler.mjs once `.js` is absent, so removing the shim is sufficient
and matches the behavior the published layer has always had.

End state:
- Sole Lambda entry point everywhere: `handler.mjs`.
- The npm tarball and the layer ship the same `dist/` (one handler file).
- No detection heuristics, no shim, no `handler.cjs` (already gone).

Aligns with:
- Darcy Rayner's recommendation on the PR thread to "only bundle the
  ESM handler" since all supported runtimes (Node 18+) support top-level
  await in ESM.
- The customer's own suggested fix in
  #782.
- SLES-2888's confirmed-working internal workaround
  (`rm dist/handler.js` post-install).
- The intent of the earlier PR #697.

Author: zarirhamza

Dockerfile

@@ -13,17 +13,6 @@ RUN yarn install
 # Build the lambda layer
 RUN yarn build
 RUN cp -r dist /nodejs/node_modules/datadog-lambda-js
-# The CJS shim at dist/handler.js exists to route ESM Lambdas through
-# handler.mjs when the npm package is used directly (the publish scripts no
-# longer copy handler.cjs to handler.js). In the layer, Lambda's bootstrap
-# resolves `handler.handler` to handler.mjs as long as handler.js is absent,
-# which handles both CJS and ESM user code via the async load(). Drop the
-# shim here so the layer keeps that direct-to-mjs behavior.
-#
-# The file being removed is shipped into dist/ by the `cp src/handler.* dist/`
-# step in scripts/update_dist_version.sh — if that script changes how
-# src/handler.js gets copied, this rm must be revisited.
-RUN rm /nodejs/node_modules/datadog-lambda-js/handler.js
 RUN cp ./src/runtime/module_importer.js /nodejs/node_modules/datadog-lambda-js/runtime
 RUN node <<'EOF'
 const fs = require("fs");

scripts/update_dist_version.sh

@@ -15,11 +15,11 @@ echo "$MAIN_CONSTANTS" |
 echo "$TRACE_CONSTANTS" |
   sed "s/\(ddtraceVersion =\) \"\(X\.X\.X\)\"/\1 \"$DD_TRACE_VERSION\"/" > ./dist/trace/constants.js
 
-echo "Copying handler js files"
-# Be explicit about which handler files ship — a broader `src/handler.*` glob
-# would also pick up `src/handler.spec.ts`, which is a test fixture, not a
-# runtime artifact. The Dockerfile's layer build also assumes `dist/handler.js`
-# is the shim from `src/handler.js`, not some other file.
-cp src/handler.js src/handler.mjs dist/
+echo "Copying handler files"
+# Only handler.mjs ships as a Lambda entry point. Lambda's bootstrap resolves
+# `dist/handler.handler` to handler.mjs (it falls through `.js` -> `.mjs`),
+# and handler.mjs's async `load()` handles both CJS and ESM user modules, so
+# a separate `.js` / `.cjs` variant is no longer needed.
+cp src/handler.mjs dist/
 cp src/init.js dist/init.js
 cp src/runtime/module_importer.js dist/runtime/