[Validation] CacheView cache keys and capacity

**Scenario contact:** @dariatiurina

## Scenario

A `CacheView` derives its cache key from where it sits in the component tree, so sections that resolve to the same position, such as one rendered repeatedly in a loop, need distinct keys. Separately, the cache has a size limit: setting it to zero prevents entries from being stored, and a small limit constrains how much can be cached while pages must still render correctly.

Validate that a key collision is reported rather than silently serving one section's output in another's place, that the cache stays correct at both ends of its capacity range, and that an edit applied through Hot Reload is not masked by a stale entry.

## Minimum build

.NET 11 RC1.

## Configurations to cover

* Blazor Web App
* [x] Static SSR
* [ ] Interactive Server
* [ ] 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
* [x] Hot Reload
* [ ] An IDE as well as the command line
* [ ] Container

Hot Reload is ticked because the cache subscribes to it and clears itself when an edit is applied.

## What to build

A small reusable component containing a `CacheView` with a cacheable child that creates a `Guid` during initialization and displays a caption. Put two copies on one page with different captions, and no `CacheKey`.

Add a second page that renders the same component in a `foreach` over five items.

Add a third page with a route parameter selecting one of several hundred generated articles. Include that article identifier in the section's cache key or vary-by configuration. Confirm that several article URLs create distinct cached entries before using this page to fill the cache.

Use the default memory store. For the concurrent-request comparison, give one cached child an atomic initialization counter and a short delay so requests overlap. Use one process, one key, enough capacity to store the entry, and a lifetime longer than the comparison.

## Things to try

* Load the page with the two copies and see what happens.
* Give each copy a distinct `CacheKey` and load it again; check both captions and both `Guid`s.
* Load the loop page, with and without a `CacheKey` derived from the loop item.
* After fixing the deliberate key collisions, set the cache size limit to zero and load all three pages.
* Set it to a small non-zero value. Confirm some articles are cached, then walk through enough distinct articles to exceed the limit and return to the first few. Record whether entries were retained, evicted, or not admitted.
* With a fresh cache and the successful same-key configuration, fire twenty overlapping requests and count how many times the cached child initialized.
* Edit the markup inside a cached section while Hot Reload is running, then reload.
* Edit the markup of a component that is inside a cached section but defined in another file, then reload.

## Expected behavior

Sections that would collide are either kept apart or reported. Capacity can affect admission, reuse, and freshness, but must not substitute one article's content for another's. Exclude diagnostic GUIDs from comparisons of otherwise identical application content.

### Must hold

* Two copies of the same cached component with no `CacheKey` either render their own content or produce an error naming the fix. Silently serving one copy's output for both is a failure.
* With a distinct `CacheKey` on each, both copies render their own caption and their own `Guid`, and each is cached independently.
* With the size limit set to zero and key collisions fixed, every load is fresh, while captions and stable application content remain correct.
* With a small non-zero limit, a returned-to article shows its own content whether its entry was retained, evicted, or never admitted.
* An edit applied through Hot Reload is visible on the very next request, for markup both inside the section and in a component it uses.
* Successful overlapping requests for the same cold key in one process share one cached-child initialization, with all responses receiving the same cached GUID.

### Expected differences between configurations

None expected.

## Evidence to capture

* The verbatim error for the colliding sections, if there is one, and the page output if there is not.
* The rendered captions and `Guid`s for both copies before and after adding `CacheKey`.
* The atomic initialization count and response GUIDs from the same-key concurrent-request test, with capacity and lifetime settings.

## Documentation to use

* [ASP.NET Core Blazor CacheView component](https://learn.microsoft.com/en-us/aspnet/core/blazor/state-management/cacheview-component?view=aspnetcore-11.0)

Report whether the docs explain when an explicit `CacheKey` is required, what the default size limit is, and what happens under concurrent cold requests.

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