perf: PropertyInjector defer state machine creation

[TimothyMakkison]

Defer async state machine creation until it's needed. Saves around 10 MB on TUnit.TestProject

• InjectPropertiesRecursiveAsync is always async so no point in defering
• InjectPropertiesAsync uses try finally so it's not possible to make the method sync
• InjectPropertiesIntoArgumentsAsync isn't referenced anywhere
• Is ParallelTaskHelper.ForEachAsync needed is InjectSourceGeneratedPropertyAsync really that slow?

Before

After

[thomhurst]

Parallel tasks is for initialisation. E.g. if 5 docker containers get injected, we want to try and speed up the initialisation of them if they're not dependent on each other.

[thomhurst]

Summary

Performance optimization that defers async state machine creation in property injection, saving ~10 MB on TUnit.TestProject.

Critical Issues

None found ✅

Suggestions

Minor optimization opportunity: The condition check on line 60 (new code) is technically redundant:

if (plan.SourceGeneratedProperties.Length > 0 || plan.ReflectionProperties.Length > 0)

Since HasProperties (checked on line 55) is true if and only if at least one of these arrays is non-empty (see PropertyInjectionPlanBuilder.cs:62,109), this condition will always be true at this point.

However, this redundancy is harmless and arguably makes the code more explicit about when to delegate to the Core method, so it's not a blocker.

Observation: The same fast-path optimization pattern is correctly applied to both ResolveAndCachePropertiesAsync and RecurseIntoNestedPropertiesAsync. The logic is preserved and the optimization is sound.

Verdict

✅ APPROVE - Valid performance optimization with no critical issues. The technique (async state machine elision for fast paths) is a well-known optimization pattern and is correctly implemented here.