fix: use ESM specifiers for NodeNext module resolution

[LordCoughmann]

Problem

Extension-less relative imports in the package declaration files fail with moduleResolution: NodeNext or Node16:

index.ts(1,15): error TS2614: Module '"@cloudflare/playwright"' has no exported member 'Browser'.
index.d.ts(2,30): error TS2834: Relative import paths need explicit file extensions...

Reproduction: https://github.com/LordCoughmann/repo-cf-playwright-esm-nodenext

pnpm install
pnpm tsc --noEmit

Solution

Use explicit ESM .js specifiers in declaration files. TypeScript's NodeNext resolver maps these specifiers to the corresponding .d.ts files, while .d.ts specifiers themselves are rejected for value imports and exports with TS2846.

• Update the hand-written declaration files to use .js specifiers.
• Post-process generated declarations to add .js extensions to relative from, declare module, and dynamic import() specifiers.
• Keep an assertion that fails if an extension-less relative specifier remains.
• Declare the package's default export as an ambient value so strict consumers can type-check without skipLibCheck.
• Add a strict NodeNext consumer fixture covering the package root entry point.

Validation

npm run build
npm run test:node-types

Both pass with moduleResolution: NodeNext and skipLibCheck: false.

[LordCoughmann]

While validating the published package shape, we noticed a separate issue: strict TypeScript consumers importing @cloudflare/playwright/test may need a playwright-core type dependency because types/test.d.ts contains typeof import('playwright-core'). This does not affect runtime imports or the package-root NodeNext fix, so we left it out of this PR. If the /test entry point should also be self-contained for strict consumers, we would be happy to discuss a follow-up.