[Validation] Live components inside a CacheView

**Scenario contact:** @dariatiurina

## Scenario

Not everything inside a cached section can be frozen into the entry. A component marked with `[CacheBehavior]` stays live by default: it runs its own lifecycle on every request while the static markup around it is served from the cache, and its parameters are captured once and replayed unchanged. A `[StreamRendering]` component inside a cached section is treated the same way.

Validate that live components really do re-render on every request, that they keep their exact place and order in the replayed output, and that nothing they render leaks from one visitor to the next.

## Minimum build

.NET 11 RC1.

## Configurations to cover

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

Interactive components inside a cached section are covered by a separate scenario.

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

Cookie authentication with two test users, and two browser profiles so identities cannot mix.

## What to build

A static SSR page with one `CacheView` containing, in this order: a cacheable child showing an initialization `Guid`, a live component showing its own initialization `Guid` and the current request's test-user name, a second copy of that live component with a different caption, another cacheable child with its own initialization `Guid`, and a streaming child that awaits a short delay before showing its `Guid`.

Mark the two live components to rerender without a condition that would include them in the cached entry. Keep the streaming attribute and delay on the streaming child, not the containing page, because a cache boundary inside a streaming subtree is not cached.

Configure the section to vary by user to keep each user's cached output separate. Give one live child a parameter whose value the parent changes on each request, and display it alongside a value generated in the child's own lifecycle. This distinguishes captured parameters from fresh execution. Use a lifetime long enough for the comparisons.

## Things to try

* Load cold, then warm, and note for every element whether its `Guid` changed.
* Compare the order and position of all five elements between the cold and the warm page source.
* Sign in as a second user, load the page to warm that user's entry, then reload it. Look at every element for the first user's data.
* Watch the streaming component on a cold load and then on a warm one.
* Give the two copies of the live component clearly different captions and check they are not swapped on a warm load.
* Reload repeatedly and confirm the live components render every time, not just the first few.
* Compare the live child's changing lifecycle value with its parent-supplied parameter across requests for the same cache key.

## Expected behavior

The static markup is replayed from cache while the live components render fresh, in their original positions.

### Must hold

* On a warm load the cacheable children's `Guid`s are unchanged while both live components and the streaming component show new ones.
* All five elements appear in the same order and position on a warm load as on a cold one.
* The two copies of the same live component keep their own captions on a warm load and are not swapped.
* On the second user's cold and warm loads, nothing inside the section shows the first user's identity.
* On a same-key cache hit, the live child runs again with the captured parameter value from entry creation, while its own lifecycle-generated value changes.

### Expected differences between configurations

* The streaming component arrives after the rest of the page on both cold and warm loads, so the warm page is complete in two stages rather than one. Record what this looks like, because it is visible to a user.

## Evidence to capture

* Cold and warm page source, diffed, with all `Guid`s and both captions visible.
* A recording of a warm load showing the streaming component arriving after the rest of the page.

## 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 that a live component's parameters are captured once and replayed, and what that means for a parameter whose value would otherwise change between 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.