[Validation] Property types for the TempData and session parameter attributes

**Scenario contact:** @dariatiurina

## Scenario

`[SupplyParameterFromTempData]` and `[SupplyParameterFromSession]` bind a component property to request-scoped storage. Session values are serialized as JSON and read back into the declared property type, so only certain types work, and a type that is not supported has to be rejected rather than silently dropped.

Validate supported property round trips for each attribute and compare how unsupported types are rejected, including the phase and diagnostic details. Do not assume the two attributes validate types at the same point.

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

* [x] Published output
* [ ] An existing .NET 10 app upgraded to .NET 11
* [x] 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

Values are deserialized back into the declared property type, so trimming is a real risk: a type that round-trips in a normal build and comes back null in a trimmed one is exactly the bug this axis catches.

## Setup

Register the session services, backing cache, and middleware. Use a supported trimmed deployment configuration for the static SSR app and record the publish command and target platform. Native AOT is not required. If the chosen hosting configuration cannot be published that way, report the configuration limitation rather than a value-serialization failure.

## What to build

Use separate setting and reading pages for the supported types, with each value represented under both attributes so their results can be compared. Do not put a deliberately unsupported property on the shared reading page, since an early rejection can prevent every other row from rendering.

For supported cases, use a `string`, an `int`, a `bool`, an int-backed enum, a `Guid`, a `DateTime`, a nullable value, a `List`, a `Dictionary`, and an array of supported elements. On isolated pages, try a POCO, a list of that POCO, and an enum with a different underlying type. Arbitrary JSON-serializable types are not automatically supported by these attributes.

Display each value together with the runtime type it came back as, so a value that survives with the wrong type is visible.

## Things to try

* For each type, set it, navigate away, come back, and check the value and the type it came back as.
* Check the values that are easy to get wrong: an enum that must not come back as a number, a `DateTime` that must not shift, a nullable set to null against one never set at all.
* Set a collection to an empty collection and to null.
* Load the page with the unsupported property type, for each attribute, and note whether it fails at build, at startup, on first render, or once the request is ending.
* Check whether anything at all is reported before the page is sent to the browser.
* Repeat the supported-type table against the chosen trimmed publish and record any relevant build or trimming diagnostics.
* Compare the isolated POCO, list-of-POCO, and non-int-backed enum cases without expecting one failure to leave the shared table usable.

## Expected behavior

Supported values round-trip into the declared property type. Rejection phase and diagnostic details can differ: the session supplier validates concrete property types during subscription, while TempData may reject a value later during persistence.

### Must hold

* A supported int-backed enum property comes back as the same enum member rather than as its numeric value, for both attributes.
* A `DateTime` property comes back with the same value and kind, for both attributes.
* A collection property comes back with the same elements in the same order, and an empty collection is distinguishable from null.
* The isolated unsupported-type cases do not silently round-trip as supported values. Record whether each fails during subscription, rendering, or persistence.
* For an unsupported concrete session property type, the rejection names the property, component type, and property type. Record the TempData diagnostic separately rather than requiring identical text or timing.
* Supported types produce the same values in the normal build and the chosen supported trimmed configuration.

### Expected differences between configurations

* Compare the supported-type results between normal and trimmed builds. A hosting configuration that is itself unsupported is distinct from a serialization regression.

## Evidence to capture

* A table of the property types tried: type, value set, value and runtime type read back for each attribute, verdict, and the trimmed-build result.
* The verbatim rejection message for each unsupported type under each attribute, and the point at which it fired: build, startup, first render, or request completion.

## 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 supported type list is documented. If it is not, the table you produce is the most useful part of your report.

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