[Validation] Keys and value lifetime for the TempData and session parameter attributes

**Scenario contact:** @dariatiurina

## Scenario

Both parameter attributes take an optional key name and fall back to the property name. The property's current value is written back at request completion. That writeback matters for lifetime: leaving a supplied TempData property unchanged can retain it rather than consuming it like an ordinary `ITempData.Get` read.

Validate how a key is chosen and matched, what happens when two components claim the same key, and how long a value bound by each attribute actually lives.

## Minimum build

.NET 11 RC1.

## Configurations to cover

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

These are static SSR features; they need an `HttpContext`, so they are not exercised in the interactive render modes.

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

Register the session services, a backing cache, and session middleware. Use nullable sample values without nonempty defaults so absence is visible. Keep the session alive during request-count comparisons, and seed a fresh identifiable value before each run.

## What to build

A page that sets values and a page that displays them, with each value declared twice, once under each attribute.

Give one property an explicit key and let another default to the property name, for both attributes. On a separate page, use a differently named property to read the same key. Keeping these readers on separate requests avoids confusing normal key-based lookup with duplicate active subscriptions.

Add a page that declares none of these properties, so you can navigate through it, and a page with two components that deliberately declare the same key.

Show the value on every page so you can see exactly which request it disappears on.

## Things to try

* Set the values, then load the displaying page twice in a row without setting anything in between, and note for each attribute which load still shows the value.
* Pass through the page that declares none of these properties, then come back.
* Read a value through a second component that uses the same key under a different property name.
* Compare an explicit key against one defaulted from the property name; then change only the case of the explicit key.
* Load the page with two components claiming the same key, for each attribute.
* Repair the duplicate-key page by giving the components distinct keys, then confirm each value can be read independently.
* Assign null to a property that currently holds a value, then reload.
* Leave a bound property untouched for several requests and see whether it survives.

## Expected behavior

A key defaults to the property name and can be set explicitly. Two active attributed properties claiming one key are rejected, so there is no successful writeback winner to measure in that case. Request-end property writeback can retain TempData values. Assigning null removes a session value, while TempData can retain a key whose value is null; both can display as no message.

### Must hold

* A property with no explicit key is stored under the property name, and a second component reading that key gets the same value.
* Two components declaring the same key throw `InvalidOperationException` naming the key, for both attributes.
* Assigning null to a bound property means the next reader displays no value. Record key presence separately if comparing removal with a stored null.
* After duplicate subscriptions are corrected to use distinct keys, each component's value can be read back without being replaced by the other.
* Within the session lifetime, a page that neither declares nor accesses the properties does not consume their stored values.

### Expected differences between configurations

* Record reads, assignments, clearing, and request-end writeback alongside the visible values. Do not assume a fixed number of requests distinguishes the attributes: unread or rewritten TempData can persist, and session data lasts until removal or session expiry.

## Evidence to capture

* For each attribute, the value shown on the request that set it and on the next three requests, with and without an intervening page that does not declare the property.
* The verbatim exception for the duplicate key under each attribute.
* Whether a key differing only in case resolved to the same stored value, per attribute.

## Documentation to use

* [ASP.NET Core Blazor state management](https://learn.microsoft.com/en-us/aspnet/core/blazor/state-management/server?view=aspnetcore-11.0#temporary-data-persistence)
* [Session and state management in ASP.NET Core](https://learn.microsoft.com/aspnet/core/fundamentals/app-state?view=aspnetcore-11.0)

Report whether the docs say how to choose between the two attributes, and whether they state how long a value bound by each one lives. The two look alike at the point of use, so this is the distinction most likely to be got wrong.

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