[Validation] CacheView expiration

**Scenario contact:** @dariatiurina

## Scenario

A `CacheView` entry's lifetime is set per section: `ExpiresAfter` for a period from creation, `ExpiresOn` for a specific moment, and `ExpiresSliding` for a window that restarts on each access. A section with no expiration configured still gets a bounded default lifetime.

Validate that each of the three options behaves as configured, that the default lifetime is what the documentation says, and that entries do not outlive the process.

## 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
* [ ] Hot Reload
* [ ] An IDE as well as the command line
* [ ] Container
* [x] N/A

## What to build

A page with four `CacheView` sections on the default in-memory store, with no `HybridCache` registered. Each section contains a child component that creates and displays a `Guid` during initialization, so an expiry is visible as that child's value changing.

Configure them as: one expiring a short period after creation, one expiring at a specific moment captured once for the run rather than recomputed on each request, one with a short sliding window, and one with no expiration configured at all. For the sliding comparison, explicitly set an absolute lifetime longer than the whole observation period so it cannot be mistaken for idle expiry.

Show the current server time outside the cached sections, plus each section's configured deadline or window.

## Things to try

* Reload the page repeatedly and record each section's `Guid` against the server time.
* For the period-based section: wait for the window to pass, reload, then reload again straight away.
* For the moment-based section: reload before the moment, then after it.
* For the sliding section: reload steadily at less than the idle window, staying inside the explicitly configured absolute lifetime, then leave it idle for longer than the sliding window.
* For the section with no expiration: reload immediately, then reload after its 30-second lifetime has passed.
* Separately, remove the sliding section's explicit absolute lifetime and record whether repeated access keeps it alive beyond 30 seconds. Report the configured options and observed expiry without assuming that a sliding window overrides every other expiration limit.
* Set an `ExpiresOn` that has already passed and load the page.
* Set both a period and a moment on one section and see which wins.
* Restart the app and reload.

## Expected behavior

Each section is served from cache until its effective lifetime runs out. The next request renders fresh content. A fixed absolute deadline that is already in the past does not create a new future caching window.

### Must hold

* The period-based section produces a new `Guid` on the first load after its window passes, and the same one on a load immediately after that.
* The moment-based section is served from cache before the configured moment and produces a new `Guid` on the first load after it.
* Before its explicit absolute deadline, the sliding section keeps the same `Guid` while it is accessed more often than its idle window, and produces a new one after it has been idle for longer than that window.
* The section with no expiration is served from cache on an immediate reload and produces a new `Guid` after 30 seconds.
* No cached content survives an app restart when using the default in-memory store.

### Expected differences between configurations

None expected.

## Evidence to capture

* A short log of reload time against `Guid` for each of the four sections, enough to show where each value changed.
* What an already-passed `ExpiresOn` did, what happened when a period and a moment were both set, and when the sliding-only variant expired under repeated access.

## 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 default lifetime is documented, and whether the docs say what happens when more than one expiration option is set.

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