Blazor WASM on IIS Express: Unable to correctly rewrite content-encoding of precompressed static file

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

I have racked my brains on this issue for a whole day but seem to have no success on this. Previously being on .NET 8, I was able to serve a WASM web app for local dev with precompressed Brotli files with extensions like `.wasm.br`, `.js.br`, `.data.br` (Unity webgl artifacts) without a problem using IIS Express with the following `web.config` (see below). As expected, all of the above precompressed files would be served with the expected content-type and encoding.

Now after upgrading to .NET 10, the file `wwwroot/assets/webgl/Build.framework.js.br` returns a 200 with the correct raw data (brotli-encoded JS), with `content-type: text/javascript` (correct) and `content-encoding: gzip` (wrong). Because of the wrong encoding returned, the browser does not automatically decode the brotli compression to show a normal JS file (which is what my application expects).

All other files with `.wasm.br` or `.data.br` seem to correctly pass through the PreCompressedBrotli condition on IIS. I sanity-checked it by changing it to something else like `value="foo"` and it reflects when fetching said resources.

Interestingly enough, if I specify a non-existent filename like `Foo.framework.js.br`, the response is (obviously) 404 with the correct `br` encoding, implying that that filename does go through the intended rewrite section.

Is there a something new on .NET 10 that changes how static files are served?

```xml

```

### Expected Behavior

_No response_

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### .NET Version
.NET 10.0.10

### Anything else?

_No response_

Start with the web.config outbound rewrite rules and reproduce the request for wwwroot/assets/webgl/Build.framework.js.br under .NET 10 with IIS Express. Compare its response headers with the working .wasm.br and .data.br files, then trace how the existing file is served. Done means the existing Brotli JavaScript file returns content-encoding: br while retaining its expected content type.

Written by the indexing model from the issue text.