Blazor Gateway: read reverse-proxy configuration from the app project's config files

## Summary

The dev-time **Blazor Gateway** (`Microsoft.AspNetCore.Components.Gateway`), introduced in .NET 11 Preview 5 (#65982) for standalone Blazor WebAssembly apps, gained the ability in Preview 6 to proxy frontend API calls to a backend service via YARP — so the client can call the backend same-origin through the gateway with no CORS. This is a great capability, but the **configuration experience is unfriendly and undiscoverable**. This issue tracks improving it, specifically by having the gateway read reverse-proxy configuration from the app project's own config files.

## Current behavior

The Gateway runs as a separate ASP.NET Core process whose **content root is the Gateway package's tools folder — not the app project directory**. As a result it does **not** read the WASM app project's `appsettings.json` / `appsettings.Development.json`. The only ways to configure the YARP `ReverseProxy` section today are environment variables (e.g. via `launchSettings.json`) or command-line args, using the double-underscore-flattened YARP schema:

```json
"environmentVariables": {
"ReverseProxy__Routes__weather__ClusterId": "backend",
"ReverseProxy__Routes__weather__Match__Path": "/api/{**catch-all}",
"ReverseProxy__Clusters__backend__Destinations__backend1__Address": "http://localhost:5100/"
}
```

Pain points:

- You **can't use the standard YARP `ReverseProxy` config section in `appsettings.json`** the way every YARP doc and tutorial shows.
- The flattened env-var keys are verbose, easy to typo, and get no schema validation or IntelliSense.
- The capability is currently **undocumented** — the only way I found to configure it was by decompiling `blazor-gateway.dll` and reading how `BuildWebHost` binds the `ReverseProxy` section.

## Proposed improvement

Have the Gateway read reverse-proxy configuration from the **app project's configuration files** (`appsettings.json` / `appsettings.Development.json`) — i.e. treat the app project directory as a configuration source so a normal `ReverseProxy` section just works:

```json
{
"ReverseProxy": {
"Routes": {
"weather": {
"ClusterId": "backend",
"Match": { "Path": "/api/{**catch-all}" }
}
},
"Clusters": {
"backend": {
"Destinations": {
"backend1": { "Address": "http://localhost:5100/" }
}
}
}
}
}
```

This reuses existing YARP knowledge and tooling, removes the env-var flattening, and makes the config discoverable and reviewable in source control. (An optional lighter-weight MSBuild/csproj item model could complement this, but reading the project's config files is the highest-value, lowest-friction fix.)

## Working sample of the current approach

A full end-to-end sample using the current env-var approach is at https://github.com/danroth27/AspNetCore11Samples (`BlazorWasmFeatures` calling `BackendApi` via the Gateway proxy, no CORS).