Change the return type from `Promise<void>` to a `Promise<'applied' |
'no-match' | 'error'>` so callers can tell a valid-but-unmatched run
apart from a worker failure. The existing load-time caller in
receive-profile ignores the value, so this is behavior-neutral.
The following file based symbolication path will use the result to show
proper errors in its UI

Pure helpers for the upcoming "apply a .map file from disk" flow:
- getSourcesWithSourceMapURL lists the profile sources that carry a
  sourceMapURL and are therefore eligible targets for a source map.
- parseSourceMapFileContents parses and validates a .map file, rejecting
  index maps.
- matchSourceMapToSource auto-matches a user-supplied map to a source by
  filename/sourceMapURL basename, returning an 'ambiguous' result (with
  candidates) when more than one source could match. Handles ?query,
  backslash paths, and the ".map"/".json" suffixes browsers append when
  saving a map served as JSON.

Add a thunk that takes a .map file the user selected from disk, parses
and auto-matches it to an eligible bundle source (or reports the match
as ambiguous so the UI can prompt), then runs it through the existing
doSourceMapSymbolication pipeline.
Unlike the WebChannel path, eligibility only requires a sourceMapURL (no
UUID id), since the map contents are supplied directly rather than
fetched.

The profiler already has a full JS source-map symbolication pipeline,
but it only runs at load time when the browser provides source maps over
the WebChannel. Profiles loaded from a file (or whose maps the browser
couldn't fetch) had no way to symbolicate JS stacks. This adds a button
in the Profile Info panel that accepts a .map file from disk and feeds
it into the applySourceMapFile pipeline.
The button is shown whenever the profile has at least one source with a
sourceMapURL. It reads the file, runs the apply action, and reports
which source was resolved, prompting with a picker when the match is
ambiguous and showing an error otherwise.