[Validation] Replacing property injection with a custom IComponentPropertyActivator

**Scenario contact:** @javiercn

## Scenario

A team wants to add auditing or app-specific context when Blazor populates injected properties. A custom `IComponentPropertyActivator` lets the team change that step without changing how components are instantiated.

This validates that Blazor uses the registered customization, that removing it restores default property injection, and that the sample works across hosting models and after publishing with trimming.

## Minimum build

.NET 11 RC1

## Configurations to cover

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

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

## Setup

Each hosting model builds components from its own service collection, so where the customization has to be registered is part of what is being tested. In a Blazor Web App with WebAssembly components, the server project and the client project are configured separately. Work out where it belongs for each configuration rather than assuming one registration covers the app, and say in the report how obvious that was.

Publish the WebAssembly configurations with trimming.

Replacing property activation applies to **every** component in the render tree, including the framework's own. The implementation must handle those components too, including types with no injected properties.

## What to build

A small app with a custom `IComponentPropertyActivator` that gives selected injected services visibly different values. Keep normal service registrations so the same pages also work without the customization.

Include ordinary, keyed, inherited, and non-public injected properties, and a component without injected properties. Log which activator populated each component. Put one deliberate activation failure on a separate page or inside an error boundary.

## Things to try

* Compare the rendered values and activation log with and without the customization.
* In a Blazor Web App with WebAssembly components, register it in only one project and observe the prerender-to-interactive handover.
* Trigger the isolated failure and inspect how it surfaces.
* Publish the WebAssembly configurations with trimming and repeat the positive cases.

## Expected behavior

Blazor uses the registered activator when creating components and falls back to its default implementation when the registration is absent. The sample's positive cases render their expected values in development and trimmed published output. Service-resolution rules and custom diagnostic wording belong to the app's implementation.

### Must hold

* With the customization registered, the visible log shows the app's own code populating properties, and the values rendered on the page are the ones it supplied.
* Ordinary injected properties, keyed injected properties, inherited injected properties and non-public injected properties are all populated.
* A component with no injected properties renders successfully while the custom activator is registered.
* The deliberate activation exception surfaces in error output or the app's error boundary rather than appearing to initialize successfully. No particular diagnostic wording is required.
* Removing only the custom activator registration restores the original service values on the positive test pages.
* In trimmed, published WebAssembly output, every injected property in the positive cases holds the same expected value as in development.

### Expected differences between configurations

* In a Blazor Web App with both server and client components, a registration made in only one of the two projects applies only to the components rendered by that project. Components rendered by the other project keep the built-in behavior, so the page can show a mixture.

## Evidence to capture

Capture the rendered values and activation logs with and without the customization, the isolated failure diagnostic, and the trimmed publish output and rendered results.

## Documentation to use

The release notes describe the extension point and show its shape, but do not say how an app makes the framework use its implementation, where that has to happen in an app that has both server and client components, or what a hand-written implementation has to do to survive publishing with trimming. Say in the report how you worked those out and how long it took.

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

Start with the release notes for IComponentPropertyActivator and the validation testing manual in issue 68479, then build the small test app across the listed Blazor hosting models. Exercise registration in the relevant server and client service collections, default fallback, injected-property variants, failure handling, and trimmed WebAssembly publishing. Done means a repository and report containing the rendered values, activation logs, failure diagnostic, and published results.

Written by the indexing model from the issue text.