Editing a collocated .js file breaks the page with an import map integrity mismatch, and dotnet watch does not fix it

## Describe the bug

With `OverrideHtmlAssetPlaceholders` set to `true` in a standalone Blazor WebAssembly project, the SDK writes a `` into `wwwroot/index.html` at build time. It lists each fingerprinted collocated JavaScript module together with its SHA-256 integrity digest.

This import map is only regenerated by a build. The dev server always serves the current content of a file on disk. So editing a collocated `.js` file and reloading the page fetches new content under the old fingerprinted file name, and the digest in the import map no longer matches it. The browser blocks the module.

`dotnet watch` does not fix this either. It serves the edited file without rebuilding `index.html`, so the digest stays stale. Every small JS edit now needs a full rebuild.

## Steps to reproduce

1. `dotnet new blazorwasm -o Repro`
2. Add this to `Repro.csproj`.
```xml
<PropertyGroup>
<OverrideHtmlAssetPlaceholders>true</OverrideHtmlAssetPlaceholders>
</PropertyGroup>
```
3. Add a collocated JS module for a component, for example `Pages/Home.razor.js` next to `Home.razor`, and import it from `Home.razor` with `IJSObjectReference`.
4. Run `dotnet watch run` and open the app in the browser.
5. Edit `Home.razor.js` (for example, add a `console.log` line) and reload the page in the browser, without stopping `dotnet watch`.

## Expected behavior

The browser loads the edited module and the page keeps working, the same as it did before `OverrideHtmlAssetPlaceholders` and the generated import map were introduced.

## Actual behavior

The browser console reports something like this, and the module fails to load.

```
Failed to find a valid digest in the 'integrity' attribute for resource
'https://localhost:7103/Home.8lc58hsgxm.razor.js' with computed SHA-256 integrity
'6armd6IWrzZFPxwY0dx+y82ip/gIOt/KNpjkoGuDyTk='. The resource has been blocked.
```

Only a full `dotnet build`, or stopping and restarting `dotnet watch`, regenerates the import map with a matching digest. It breaks again on the next edit.

## Is this a regression?

Yes. A standalone Blazor WebAssembly project without `OverrideHtmlAssetPlaceholders` does not have this problem, because collocated JS files are not listed in an import map with a digest.

## Are there any workarounds?

None found. Turning `OverrideHtmlAssetPlaceholders` off avoids the error, but it also turns off the feature I am trying to use.

## dotnet --info output

```
.NET SDK: 10.0.400
Runtime Environment: Windows 10.0.26200, RID win-x64
Host: 11.0.0-preview.7.26381.103
```

## IDE version

Not applicable. I reproduced this from the command line with `dotnet watch run`.

## Other details

This looks related to [dotnet/sdk#53331](https://github.com/dotnet/sdk/issues/53331), but with a different root cause. That issue is about `blazor.webassembly.js` getting a new fingerprint on every rebuild, which breaks Hot Reload. This issue is about a collocated JS module's digest going stale in the import map.

Start with the generated wwwroot/index.html and the dotnet watch path described in the reproduction, focusing on how the import map records collocated .js modules and their integrity digests. Reproduce the edit-and-reload sequence with OverrideHtmlAssetPlaceholders enabled, then verify that editing Home.razor.js no longer leaves a stale digest and the browser loads the module without a full rebuild.

Written by the indexing model from the issue text.