Allow Chrome to exit after forced exporter termination

[daniatic]

On Windows, forcibly stopping a Node process that initialized highcharts-export-server@6.0.0 can leave chrome-headless-shell.exe running after Node has exited. The leftover browser consumes resources and may keep its user data directory in use, interfering with a later exporter launch using the same directory.

The reproduction is to initialize the exporter, forcibly stop its Node PID with Stop-Process -Id <pid> -Force, and check whether the Chrome PID remains. The export server's graceful cleanup cannot run after a forced termination. In our local comparison, Chrome survived with WebSocket transport and exited with its Node owner when Puppeteer's pipe transport was enabled.

The export server currently provides no normal configuration option for that transport. Passing pipe through its debug options also requires enabling browser debug mode and adjusting unrelated launch settings.

This PR lets applications opt into pipe transport with puppeteer.pipe or PUPPETEER_PIPE, while keeping the default false. It forwards the option to Puppeteer and rebuilds the checked-in ESM and CommonJS bundles through the existing package entry points. The README and sample environment file document the setting and the README explains its incompatibility with a nonzero debugging port.

Validation with Node 24.15.0:

• npm run build passed.
• npm run unit:test -- --runInBand passed all 58 tests across 6 suites.
• Full-repository ESLint completed with zero errors and two import warnings. Running the same check on unchanged master produced the same two warnings.
• Both built package entry points honored PUPPETEER_PIPE=true; an explicit module setting could override it.

Validation with Node 22.22.2:

• Five suites passed with all 46 tests in those suites passing. The sanitizer suite failed to load because Jest's require(ESM) support for a jsdom dependency requires Node 24.9 or newer.
• The same sanitizer loading failure occurs on unchanged master at 9675410d14aaa6dd2009b244262cf637040f3d93, using the same locked dependencies. Its other five suites passed all 45 tests.

Fixes #687

[daniatic]

Withdrawing this PR because the reported Windows failure was caused by a Puppeteer browser-launcher regression and is resolved by @puppeteer/browsers 3.2.2. Pipe transport is unnecessary for that failure. The corrected diagnosis and validation are in the closing note on #687. Issue #686 already tracks a Puppeteer dependency update.