[Validation] What QuickGrid's URL navigation changes for an existing app

**Scenario contact:** @dariatiurina

## Scenario

Because `QuickGrid` sorting and paging now go through the URL, its column headers and paginator controls render as links rather than buttons. Upgrading the QuickGrid package from .NET 10 to .NET 11 changes the default controls, which can break UI selectors and alters what a static SSR page does. An `AppContext` switch restores button rendering, not necessarily every aspect of the previous URL behavior.

Validate what an upgraded app sees, that the switch really brings the old behavior back, and that it still does so in a trimmed build.

## Minimum build

.NET 11 RC1.

## Configurations to cover

* Blazor Web App
* [x] Static SSR
* [x] Interactive Server
* [ ] Interactive WebAssembly
* [ ] Interactive Auto
* [ ] Standalone WebAssembly
* [ ] Hybrid (MAUI)

## Also exercise

* [x] Published output
* [x] An existing .NET 10 app upgraded to .NET 11
* [x] Trimming or ahead-of-time compilation
* [ ] More than one server instance, or a proxy in front
* [ ] Hot Reload
* [ ] An IDE as well as the command line
* [ ] Container

The upgrade is the scenario. Trimming is included because the switch is a trimmer-substitutable feature switch, so a trimmed build could bake in the wrong value and ignore the configuration entirely.

## Setup

Build a small .NET 10 Blazor Web App first: one static SSR page with a sortable `QuickGrid` and a `Paginator`, and one Interactive Server page with the same grid. Record the markup, URLs, and any existing UI-test selectors. Then retarget to `net11.0`, use the tested .NET 11 SDK, and update the QuickGrid package to a matching .NET 11 version while preserving application code and selectors. Record the resolved package versions - a TFM change alone does not upgrade QuickGrid.

Apply runtime switch settings before the grid is first used and restart between configurations. For a supported trimmed publish, set the intended build-time feature-switch value before publishing and rebuild when changing it. A runtime setting cannot restore code removed by the trimmer. Native AOT is not required.

## What to build

Nothing new at first: keep the application's UI and data unchanged while upgrading the framework and package, then characterize the difference.

Then apply the switch that restores the old controls, working out from the docs where that configuration belongs.

## Things to try

* Compare the rendered column header and paginator markup before and after the upgrade, in both render modes.
* Run the .NET 10 UI-test selectors against the upgraded app.
* On the static SSR page, sort and page and see what now happens.
* Apply the switch before the first grid use, restart, and check the controls. If you try different configuration locations, record the value, timing, and restart or publish required for each.
* With the switch applied, put sort and page values in the URL by hand and see whether the grid still reacts to them.
* With the switch applied, check whether the static SSR page can still be sorted at all.
* Repeat against the chosen supported trimmed configuration, recording the build-time switch value and publish command. A failure to publish an unsupported hosting configuration is not a switch-behavior result.
* Set the switch to its non-default value and then remove it again, confirming the app returns to the new behavior.

## Expected behavior

Sorting and paging start working on static SSR pages that previously did nothing, and the URL now changes on interactive pages too. The switch restores button-based markup. Record URL-state behavior separately rather than assuming the switch rolls back all navigation behavior.

### Must hold

* After the upgrade with default settings, a sortable header in static SSR renders as `` and the paginator renders `go-first`, `go-previous`, `go-next` and `go-last` anchors.
* With the switch applied, the header renders as `` and the paginator renders `` elements carrying `disabled` at the ends of the range.
* With the intended switch value configured before runtime initialization or trimming, the chosen supported trimmed publish renders the same control kind as the normal build.
* Removing the switch returns the app to the anchor-based controls.

### Expected differences between configurations

* Static SSR changes the most: sorting and paging go from doing nothing to working, and each interaction becomes a navigation.
* Interactive Server looks the same to a user, but the URL now changes and Back and Forward now move through grid states.

## Evidence to capture

* The rendered markup of one column header and of the paginator, before the upgrade, after it, and again with the switch applied.
* The exact configuration used for the switch and the file it lives in, plus which of the places you tried had no effect.
* Selectors affected by the button-to-anchor change. Record other upgrade differences separately instead of treating every unrelated selector failure as a defect in this feature.

## Documentation to use

* [ASP.NET Core Blazor QuickGrid component](https://learn.microsoft.com/aspnet/core/blazor/components/quickgrid?view=aspnetcore-11.0)
* [Breaking changes in .NET 11](https://learn.microsoft.com/dotnet/core/compatibility/11.0)

Report whether the change from buttons to anchors is listed as a breaking change, and whether you could find the switch's name from the docs alone. A team hitting this finds it as failing UI tests, not as a documented feature.

## What to report

Report results using the format described in the [validation testing manual](https://github.com/dotnet/aspnetcore/issues/68479). Include link to a repository with the test app.