Added a SourceMapRunner type and an optional `run` argument to
doSourceMapSymbolication through applySourceMapFile, to make the source
map symbolication runner injectable. The default behavior stays as the
Web Worker runner, but let's the non-browser callers inject a runner
that calls the core logic directly, since the profiler-cli Node daemon
has no Workers.

`ApplySourceMapFileResult` only carried the resolved bundle source's
filename, which is all the web UI needs. Add the source table index
alongside it, so callers that identify sources by index rather than by
name can report which source the map landed on. A follow-up uses this to
add "sourcemap" commands to profiler-cli, which refers to sources by
"src-N" handles.

Lists the bundle sources that carry a `sourceMapURL` and are therefore
eligible to have a `.map` applied to them -- the same set the web app's
"Apply source map…" picker offers. Each gets a `src-N` handle, which is a
direct index into `profile.shared.sources` and so is stable across
sessions for the same profile, like `f-N`.
Firefox stores an inline map's entire `data:` URL in the source table, so
a "URL" can be megabytes of base64. Those are reported by media type and
size instead, which keeps the payload out of both the text and `--json`
output.
The integration fixtures are pre-generated and committed because the
profile builders are DOM-coupled and can't run in the node-env test
process, so sourcemap-generator.ts regenerates them via a browser-env
test.
A follow-up adds "sourcemap apply", which consumes these handles.

Brings the web app's "Apply source map…" feature to profiler-cli, reusing
the shared `applySourceMapFile` thunk. Since the CLI is one-shot, the web
picker becomes a two-step flow: "sourcemap sources" lists the candidates,
then "sourcemap apply <path> [--to src-N]" reads the .map on the daemon,
auto-matches it to a source (or applies to the source given by --to) and
re-symbolicates in place. Ambiguous matches and errors exit non-zero so
scripts can branch on them.
The daemon has no Web Worker, so it injects a runner that calls the
symbolication core directly on the current thread. That core's `source-map`
dependency reads its WASM parser from `path.join(__dirname,
'mappings.wasm')` at runtime, and esbuild does not bundle that file, so the
build copies it next to the bundle and the publish check now fails if it is
missing -- without it, "sourcemap apply" silently applies nothing.
`--to` only accepts sources that carry a `sourceMapURL`, the same set the
web picker offers. Applying a map to any other source would skip the
auto-match step's `no-eligible-sources` guard and then de-minify nothing,
which reads as a successful apply.

Adds a SOURCE MAPS section covering the sources -> apply flow and the
--to disambiguation step, and lists src-N in the handle reference tables
alongside t-N / f-N / c-N / ts-N.