[Validation] Virtualized QuickGrid: initial position, scrolling and prepended data

**Scenario contact:** @ilonatommy

## Scenario

A virtualized `QuickGrid` can now open already scrolled to a given row, be scrolled programmatically at any later point, and keep the viewport anchored when an asynchronous items provider returns rows that were inserted above the ones already on screen. Earlier versions also fetched some ranges twice.

Validate that the grid lands on the requested row, that a programmatic scroll can be superseded, and that a stable item stays under the user's eyes when rows arrive. Record provider requests so a redundant load can be distinguished from a legitimate measurement, cancellation, or range adjustment.

## Minimum build

.NET 11 RC1.

## Configurations to cover

* Blazor Web App
* [ ] Static SSR
* [x] Interactive Server
* [x] Interactive WebAssembly
* [x] 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

## Setup

QuickGrid's anchoring mode and item comparer are experimental and produce build diagnostic `ASP0030` when used. Record what the compiler said, what its link led to, and what you added to the project.

## What to build

A page with a virtualized `QuickGrid` in a fixed-height scroll container, fed by an items provider over 100,000 generated rows with a short controllable delay so placeholder rows are visible. Display each item's stable identity separately from its current index, since prepending changes indices. Use stable instances, value equality, or a comparer based on identity. Show placeholder indices and row borders so alignment is visible.

Use an explicit anchoring mode, record it, and notify the grid when the provider's data changes. Keep timers and manual scrolling off during initial-position and supersession comparisons so those inputs do not compete.

Add:
- a box that sets the row the grid opens at,
- a button to load the grid after the index is set,
- a "jump to row" button that scrolls to an arbitrary index at any time,
- a filter that changes the total row count,
- a toggle that starts a timer prepending/appending new rows at the top/tail every few seconds,
- a provider log with start index, requested count, data version, cancellation, and the interaction that caused each request.

## Things to try

* Open the page with the initial row set to 0, "jump" to a middle index, to the last index, past the end, and to a negative number.
* Record initial-load requests separately from later interactions. Do not treat every repeated range as a duplicate-load defect: layout measurement, changed totals, and canceled requests can require another fetch.
* Scroll slowly, drag the scrollbar quickly, and use Home key and End key.
* Start a second programmatic jump before the first has completed, once with nearby targets and once with distant targets. Observe the final target after both operations settle, distinguishing this from two sequential completed jumps.
* Call the programmatic scroll on a grid with virtualization turned off.
* Turn on the prepend timer, leave the mouse pointer resting on a row in the middle of the list, and watch whether the content under it moves.
* Turn on the append timer, leave the mouse pointer resting on a row in the middle of the list, and watch whether the content under it moves.
* Change the filter and record the provider requests and total count, distinguishing a range correction from an unnecessary duplicate request.
* Resize the window and zoom to 150% while scrolled into the middle.
* On Auto, compare the same initial row in a fresh browser profile and after the WebAssembly resources have downloaded. Record the renderer actually selected instead of assuming every later visit runs on WebAssembly.

## Expected behavior

The grid renders only what is near the viewport, opens at the requested row, and stays where the user is looking when rows arrive.

### Must hold

* With the initial row set to a middle index N, the first row at the top of the scroll area is row N, and the provider's first logged start index is near N rather than 0.
* An initial row past the last row lands on the last rows; a negative one lands on the first row. Neither throws.
* When a second jump supersedes an in-flight first jump and no other navigation intervenes, the grid settles on the second target.
* Calling the programmatic scroll when virtualization is disabled throws `InvalidOperationException`, and the message names both the method and the `Virtualize` parameter.
* With the user in the middle of the list and the configured anchoring mode active, the same item identity remains under a fixed screen position after three prepend or append batches, even though its index may change.
* While the data set remains unchanged during the request, a placeholder's index matches the data row that replaces it.

### Expected differences between configurations

* Placeholder visibility depends on provider latency, rendering, and the browser. No relative speed or frame-count ordering is required between render modes.
* Auto can select different renderers across visits. Compare the resulting item and viewport position after identifying the renderer used in each run.

## Evidence to capture

* The stable item identity, index, and viewport position before and after initial positioning, superseding jumps, and data insertion.
* Provider request logs grouped by interaction, including counts, cancellation, and total changes.
* The selected renderer for each Auto run and any experimental diagnostic encountered during setup.

## Documentation to use

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

Report whether the initial index, the programmatic scroll, the anchoring mode and the comparer were findable from the docs, and what the `ASP0030` link told you.

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

Start with the QuickGrid and component virtualization documentation, then follow the validation testing manual to build the described test app. Exercise the initial position, superseding jumps, provider logging, anchoring, comparer, and configuration matrix; done means recording the required evidence, diagnostics, renderer selection, documentation findings, and repository link.

Written by the indexing model from the issue text.