[Validation] TempData across a redirect in static SSR

**Scenario contact:** @dariatiurina

## Scenario

Blazor now has `ITempData` for static SSR, which supports a "saved successfully" message after a redirect. An ordinary read marks a value for removal at the end of the request, `Peek` reads without consuming it, and `Keep` retains it for a later request. A component property can also be bound to a key with `[SupplyParameterFromTempData]`, which reads the value and writes the property's current value back at request completion.

Validate a one-time message flow, the difference between read, peek, and keep, and that a page which never touches TempData does not consume it.

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

## What to build

Two static SSR pages. The first has a form that writes a message to TempData and redirects to the second. The second shows the message if there is one and nothing otherwise.

Write the reading page twice: once taking `ITempData` as a cascading value and consuming the key, and once with a property bound by `[SupplyParameterFromTempData]`. In the bound-property version, copy the supplied message into a separate display field and clear the bound property after reading it, so request-end writeback does not retain the message. Keep an untouched-property variant to observe that writeback separately.

Add a page that peeks, a page that reads and keeps once, and a page that does not touch TempData. After the keep-once page, use an ordinary consuming reader, not a page that keeps the value again. Seed a fresh identifiable message before each comparison.

## Things to try

* Submit the form, land on the reading page, then refresh it.
* Submit, then navigate away and come back.
* Open the reading page directly with no prior submit.
* Store a value and pass through the page that never touches TempData before reading it.
* Read with peek, then reload; read normally, then reload.
* Read and keep once, then read normally on the next request and refresh that ordinary reader.
* Peek and then keep the same value in one request.
* Read the same key twice within a single request.
* Compare the two reading pages: the bound property and the cascading value, for the same stored value.
* Leave the bound property unchanged in its separate variant and record whether repeated requests retain it.
* Write a value and read it back within the same request, before any redirect.

## Expected behavior

An ordinary read marks the value for removal after the current request, so reading it twice in that request can still return the value. Peeking, keeping, and writing the value back retain it. A one-time message requires a consuming read with no subsequent writeback, or an explicitly cleared bound property.

### Must hold

* After the submit and redirect the ordinary consuming reader shows the message once; refreshing it shows nothing.
* A value that is not read on the following request is still readable on the request after that, and passing through a page that never touches TempData does not delete it.
* A peeked value is still readable on the next request.
* After a read-and-keep request, the next ordinary consuming reader sees the value. Refreshing that reader then shows nothing.
* The bound-property reader that explicitly clears its property produces the same one-time display as the ordinary consuming reader.

### Expected differences between configurations

None expected.

## Evidence to capture

* For each fresh message, the read, peek, keep, or property-writeback operation performed and what each following request displayed.
* What reading the same key twice in one request returned each time.

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

Report whether the docs distinguish reading from peeking clearly enough that you would pick the right one without experimenting.

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