I think I've had the same issue that you're maybe describing - and I'm yet to find a satisfactory solution.

In my use case I want to be able to run and debug the Blazor WASM app as normal from Visual Studio which means the app would be at something like: https://localhost:7276/test/. I also like to publish to my local IIS so then I can hit my app on something like: https://localhost:7276/. While running on IIS it more closely matches my other deployment stages and it also means the app is more easily testable on other devices.

My horrible workaround I'm very keen to replace goes like this... In my index.html I have <base href="/" /> I then copy the same index.html to published_index.html and change the base to: <base href="/test/" />. Finally I add a step in the web app's .csproj file like this:

<Target Name="PostPublishTask" AfterTargets="AfterPublish">
    <Message Text="Copying published_index.html to index.html" Importance="high" />
    <Exec Command="@ECHO F|XCOPY wwwroot\published_index.html bin\Release\net9.0\browser-wasm\publish\wwwroot\index.html /f /y" />
</Target>

All this does is copy the published_index.html file over the index.html in the published location when I press publish. Once I've mounted the app in IIS as 'test' I can hit it as explained above. It's the least awful of the solutions I've found as basically I can forget about it. The only issue is a few extra minutes setting up the apps in IIS to begin with. My CI/CD deploy pipelines will do the same copy of published_index.html if they find it so they just work too.

I should mention that my apps locally consist of the Blazor WASM app and the API. All of the time my Blazor app is pointing to the API as hosted in IIS (in my case https://MYMACHINENAME:5000/test/api/...) . If I want to debug the API I run that only from Visual Studio and use Swagger or Postman to pass the correct data to trigger breakpoints and suchlike.