[javascript] Create @seleniumhq/atoms npm package from TypeScript atoms - #17459

🔗 Related Issues

Builds on the Closure → TypeScript atom migrations (#17458 and siblings), which are already on trunk.

💥 What does this PR do?

Turns the three TypeScript atoms (get-attribute, find-elements, is-displayed) into real ES modules and compiles them down two independent paths from the same sources:

• IIFE path (language bindings) — ts_project with --module commonjs, then a new cjs-to-iife.js post-processor emits browser-injectable (function(){ … return fn; })(). Python, Ruby, Java and .NET consumers see byte-compatible output and are unchanged.
• npm path — ts_project with --module esnext, declaration, declarationMap and sourceMap into dist/, packaged as @seleniumhq/atoms with full .d.ts type declarations.

Both paths type-check the same .ts sources, so the published package and the injected atoms can't drift apart.

🔧 Implementation Notes

Atom sources

• Removed the outer IIFE from get-attribute.ts, find-elements.ts and is-displayed.ts; each now ends in export default <fn>.
• Added index.ts as the package entry point, re-exporting the three atoms as getAttribute, findElements and isDisplayed.

Build wiring (javascript/atoms/BUILD.bazel)

• Replaced the three js_run_binary + tsc --module none --outFile invocations with ts_project targets.
• Replaced the strip_trailing_semicolon binary with cjs_to_iife, which strips the CommonJS boilerplate tsc emits and wraps the remaining body in an IIFE returning the default export.
• Updated the three wrap-*-as-global.js scripts to parse CJS-compiled input rather than asserting the file starts with (function () {.
• Added atoms-npm-compiled (ts_project → dist/) and selenium-atoms-package (npm_package, publishable = True, tagged release-artifact).

One tsconfig per ts_project target
Each atom gets its own tsconfig-<atom>.json with a single-entry files list, rather than sharing one tsconfig-cjs.json across all three. A shared tsconfig makes several ts_project targets declare the same file as an input, which Bazel materialises concurrently into the same sandbox path — on Windows that races and fails with EPERM. Per-target configs give each action a disjoint input set. (tsconfig.json at the package root stays shared, because only atoms-npm-compiled uses it.)

Package metadata
javascript/atoms/package.json is promoted to @seleniumhq/atoms with exports entries for the package root and each individual atom.

✅ Verification

• bazel build //javascript/atoms:selenium-atoms-package //javascript/atoms:atoms-npm-compiled plus the three *-typescript-compiled targets — clean.
• bazel build //javascript/selenium-webdriver/lib/atoms:all //rb/lib/selenium/webdriver/atoms:all — clean; the generated IIFE output still ends in return get; })();, so the injection path is unchanged for bindings.

💡 Additional Considerations

• package.json currently declares "main": "./dist/index.cjs" and a "require" condition on every export, but the npm path only emits ESM .js + .d.ts — no .cjs is produced. Either the CJS conditions should be dropped (ESM-only package) or a second ts_project should emit the .cjs outputs before this is published. Flagging for a decision before release.
• The package version tracks the repo's nightly version string; it will need the usual release-tooling treatment the first time it ships.

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): Claude
  • What was generated: Templates
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• New feature (non-breaking change which adds functionality)
• Cleanup (build wiring, formatting)