[release/11.0] Ensure async validation tasks are cleaned up during initialization

[github-actions]

Backport of #132685 to release/11.0.

/cc @jeffhandley

Customer Impact

• Customer reported
• Found internally

Async DataAnnotations validation is new in .NET 11. During task fan-out, setup could fail after some validation tasks had started but before execution entered the try/finally cleanup scope.

Those tasks could outlive the public Validator call and continue using the caller-owned object, ValidationContext, or services after the caller resumed or disposed them. This leaves the new async-validation scenario significantly incomplete and creates a reliability risk from escaped background work and resource-lifetime races.

The fix moves task creation inside the existing cleanup scopes, ensuring every started task is cancelled and awaited before control returns.

This meets the .NET 11 bug bar as:

• Changes needed based on threat modeling / security review.
• A broken or significantly incomplete scenario for a feature new in the release.
• A significant reliability issue.

Regression

• Yes
• No

This is not a regression from .NET 10 because async DataAnnotations validation was introduced in .NET 11 by #128656. It completes the lifetime guarantees of that new feature.

Testing

On main:

• System.ComponentModel.Annotations built successfully.
• System.ComponentModel.Annotations.Tests passed: 984 passed, 0 failed.

Existing tests cover parallel async validation, cancellation, short-circuiting, and result collection. No targeted test was added because the protected path requires a synchronous failure during internal fan-out setup, which cannot be injected deterministically through the public API without white-box manipulation.

The same component tests and PR CI validate the backport on release/11.0.

Risk

Low. The change modifies one private implementation file, adds no API, and does not alter normal validation results or task ordering. It only extends the existing cancellation-and-await cleanup boundary to cover failures during task setup.

On exceptional setup paths, the method may wait for a non-cooperative validator before propagating the original exception. This is intentional because returning while validation still uses caller-owned state is the reliability problem being fixed.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-componentmodel-dataannotations
See info in area-owners.md if you want to be subscribed.

[jeffhandley]

@artl93 I recommend this PR for .NET 11 RC2. The need for this change was identified during security review.

[artl93]

Quality. New scenario. Approved.

[tarekgh]

nit (non-blocking): the cancel-and-await cleanup is the right call. The one residual edge is a validator that ignores its CancellationToken, since after linkedCts.Cancel() we still await it, so a non-cooperative validator can delay both the exceptional path and the normal breakOnFirstError short-circuit. A timeout wouldn't help, it would just trade the hang for returning while a rogue task still uses caller-owned state.

Could we instead make the contract explicit as a docs-only follow-up? Add a remark on AsyncValidationAttribute.GetValidationResultAsync that implementations must observe the token, and that callers wanting an upper bound should pass one linked to a timeout (new CancellationTokenSource(timeout).Token). Not a blocker for the backport.