Problem

denoland/deno#30750 reports a Deno.bundle failure when bundling an HTML entrypoint whose <script> references a TS module, using sourcemap: 'external' + platform: 'browser'.

While investigating I found a concrete, reproducible defect in exactly that configuration: when bundling an HTML entrypoint with --sourcemap=external (or linked), the emitted sourcemap file leaks the internal virtual-entry name instead of matching the JS bundle.

Repro (no remote modules needed):

deno bundle --unstable-bundle --outdir ./dist --sourcemap=external index.html

where index.html has <script src="./index.ts" type="module">.

Before:

dist/index-NWUVJ7TJ.js
dist/index.deno-bundle-html.entry-NWUVJ7TJ.js.map   <- leaks internal name
dist/index.html

In linked mode the JS //# sourceMappingURL= comment also pointed at the leaked index.deno-bundle-html.entry-…js.map name.

After:

dist/index-NWUVJ7TJ.js
dist/index-NWUVJ7TJ.js.map                          <- matches the bundle
dist/index.html

and the sourceMappingURL comment is rewritten to index-NWUVJ7TJ.js.map.

Change

HTML entrypoints are bundled via a virtual module named <entry>.deno-bundle-html.entry.js; esbuild emits the bundle as <entry>.deno-bundle-html.entry-HASH.js and patch_html_with_response renames it back to the original <entry>-HASH.js. The sibling .js.map was never renamed.

This patch renames the .js.map alongside its JS bundle and, for linked sourcemaps, rewrites the JS sourceMappingURL reference to the new name. inline sourcemaps (embedded data URL) and the no-sourcemap case are unaffected.

Tests

Added a sourcemap case to tests/specs/bundle/html/ that bundles with --sourcemap=external and asserts:

• no output file leaks the deno-bundle-html.entry name,
• the .js.map is named to match the JS bundle,
• the sourcemap still resolves its original source.

All existing bundle::html spec tests and the tools::bundle::html unit tests pass; cargo clippy -p deno is clean.

Note on the "channel closed" panic

The literal channel closed panic in the issue title surfaces when the bundling worker thread panics (the provider's oneshot is dropped, so op_bundle rejects with the RecvError message). I could not reproduce that panic on current main (macOS) — HTML bundling with the reporter's config now completes successfully; the reporter is on Windows. The panic appears to have already been addressed (likely the bundle HTML rewriter refactor in #34408), leaving the sourcemap mis-naming as the remaining reproducible defect in the reporter's exact sourcemap: 'external' + HTML scenario, which this PR fixes.

Closes #30750

Closes denoland/divybot#492