[Validation] Forms and interactive components inside a CacheView

**Scenario contact:** @dariatiurina

## Scenario

A form's antiforgery token and an interactive component's marker are both generated per request. If either were frozen into a cache entry and replayed, form posts would start failing validation and interactive components would stop hydrating.

Validate that a form inside a cached section still submits on a warm page, and that interactive Server and WebAssembly components inside one still become interactive.

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

The page and cache boundary remain static SSR. The interactive modes apply to separate child components inside the boundary, not to a globally interactive parent.

## 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 static SSR page with one `CacheView` containing a cacheable child that creates and displays an initialization `Guid`, an `EditForm` with a required field and validation that posts back to the same page, an interactive Server child with a button and counter, and an interactive WebAssembly child with a button and counter. Register both interactive modes and keep prerendering enabled for the two children.

Choose an expiration long enough to finish a cold/warm comparison after both children become interactive. Once that comparison is complete, deliberately wait past the deadline to exercise expiry.

## Things to try

* Load cold, then warm, and confirm the cached child's `Guid` is unchanged before comparing the antiforgery token. A working uncached page is not enough to pass this scenario.
* Submit the form on a warm page with a valid value, and with the required field empty.
* Submit repeatedly, including after the entry has expired and been recreated.
* Click both counters on a warm page, several times each.
* Reload a warm page and click the counters again.
* Compare the interactive component markers between cold and warm loads. Inspect their per-render prerender identifiers, not stable fields such as the component type or location key.
* Leave the page open past the expiration, then submit the form.

## Expected behavior

Per-request values are regenerated on every request even though the markup around them is replayed.

### Must hold

* A warm GET retains the cached child's `Guid` while generating a different antiforgery token.
* Submitting the form on a warm page succeeds and the submitted value is accepted.
* Submitting with the required field empty shows the field's validation message rather than an error page.
* Both interactive components respond to a click on a warm load, incrementing their counters.
* With prerendering enabled, the interactive children receive new prerender identifiers on a warm GET even though the surrounding cached child's `Guid` is unchanged.
* Submissions and clicks still work after the entry has expired and been recreated, and after reloading a warm page several times.

### Expected differences between configurations

* The Server and WebAssembly markers have different formats, which is expected.
* A cold WebAssembly visit may need a runtime download before interactivity. Record readiness without requiring either render mode to be faster.

## Evidence to capture

* The antiforgery token and both component markers from a cold and a warm load, side by side.
* A recording of a successful form submission, an empty-field submission, and both counter clicks on a warm 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 say that forms and interactive components are safe inside a cached section, since a developer has no way to tell by looking at the markup.

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