[Validation] QuickGrid paging and the Paginator

**Scenario contact:** @dariatiurina

## Scenario

`Paginator` now moves between pages through a query string parameter and ordinary links, so a grid on a static SSR page can be paged, and a page of results can be bookmarked. The controls at the ends of the range are marked as disabled for assistive technology rather than being rendered as disabled buttons.

Validate that paging works with no interactivity, that the page parameter behaves as documented at the first page, and that the disabled state at each end of the range is correct for both mouse and keyboard.

## Minimum build

.NET 11 RC1.

## Configurations to cover

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

## Also exercise

* [ ] Published output
* [ ] An existing .NET 10 app upgraded to .NET 11
* [ ] 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
* [x] N/A

## What to build

A page with a `QuickGrid` over an in-memory list of 60 or so items and a `Paginator` with a page size of five, so there are twelve pages to move through. Number the items so the current page is obvious from the rows.

Use the same grid in static SSR (no `@rendermode`), Interactive Server, and Interactive WebAssembly variants. Let the grid and paginator own their navigation without custom `NavigationManager` calls or query-string code.

## Things to try

* Move forward one page at a time and watch the address bar; then jump to the last page and back to the first.
* Copy the URL from the middle of the range and open it in a private window.
* Compare `page=0`, `page=1`, a negative page, and a non-numeric value on fresh direct loads. Separately try a positive page beyond the available range and record the resolved page and visible rows, including whether the total was already known.
* At the first page, try the "first" and "previous" controls with the mouse and keyboard. Record the generated destination and whether the visible page changes; an anchor's ARIA-disabled state is not the same mechanism as an HTML button's `disabled` attribute.
* Do the same with "next" and "last" at the last page.
* Tab through the paginator at the first page, in the middle, and at the last page, and note where focus stops.
* Middle-click a paginator arrow to open it in a new tab.
* Use browser Back and Forward after several page changes.
* Try a page size that divides the item count exactly, and one that leaves a partial last page.

## Expected behavior

For an unchanged data set, a valid page URL reproduces the same rows. Malformed or nonpositive page values fall back to the first page. A positive number beyond the available range takes a different path and can be clamped when the total becomes known or changes; record that case separately rather than requiring a universal first-page fallback.

### Must hold

* In static SSR the paginator's controls render as `` elements with `href` values, with the classes `go-first`, `go-previous`, `go-next` and `go-last`.
* Moving to the second page puts `page=2` in the URL.
* Returning to the first page removes the page parameter from the URL entirely.
* On the first page the "first" and "previous" links carry `aria-disabled="true"` and `tabindex="-1"`, and Tab does not stop on them; the same holds for "next" and "last" on the last page.
* On a fresh direct load, a malformed or nonpositive page parameter renders the first page and returns HTTP 200.

### Expected differences between configurations

* Static SSR paging requests new server-rendered content, possibly through enhanced navigation without a full document reload. Interactive variants update the URL and rerender the grid.

## Evidence to capture

* The rendered paginator markup at the first page, in the middle of the range, and at the last page, with the `href`, `aria-disabled` and `tabindex` values visible.
* The URL and the visible item numbers after each of: the first load, a move to page 2, and a move back to page 1.
* The requested and resolved page for a positive page number beyond the range, together with the total item count and how the page was loaded.

## Documentation to use

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

Report whether the docs say that the page parameter is one-based and that the first page carries no parameter, since anyone writing a link to a specific page needs both facts.

## 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.