fix: skip IResourceWithoutLifetime resources in Aspire fixture wait logic

[thomhurst]

Summary

• Aspire 13.2.0 introduces internal {name}-rebuilder resources for .NET Project resources that appear in DistributedApplicationModel.Resources but never transition to Running/Healthy
• AllHealthy/AllRunning wait modes now filter out IResourceWithoutLifetime resources (data-holder/reference resources with no lifecycle) before waiting, preventing indefinite hangs
• Skipped resources are logged via LogProgress for visibility

Fixes #5260

Test plan

• Verify TUnit.Aspire builds on all target frameworks (net8.0, net9.0, net10.0)
• Verify Aspire integration tests pass with Aspire 13.2.0 AppHost that includes project resources (which now have companion rebuilder resources)
• Verify AllHealthy mode no longer hangs on rebuilder resources
• Verify AllRunning mode no longer hangs on rebuilder resources
• Verify Named mode is unaffected (does not use the new filter)
• Verify skipped resources appear in log output

[claude]

Code Review

This is a clean, well-scoped fix for the Aspire 13.2.0 regression. Here's my analysis:

What's good

Correct interface check. Filtering on IResourceWithoutLifetime is the right seam — these are data-holder/reference resources that Aspire explicitly marks as having no lifecycle, so waiting for them to become Running/Healthy is inherently meaningless.

Lazy allocation is consistent with TUnit's performance-first principles. Using skipped ??= [] avoids allocating the skipped list in the common case where all resources have a lifecycle, which is a nice touch.

Named mode is correctly excluded from the filter. If a user explicitly opts in to waiting for a specific resource by name, they've made that decision — silently filtering it would violate the principle of least surprise. The PR description correctly calls this out.

Early return in WaitForResourcesWithFailFastAsync is already there (resourceNames.Count == 0), so the edge case where every resource is IResourceWithoutLifetime is handled gracefully without any additional changes.

Logging skipped resources provides the right amount of visibility — future readers won't wonder why rebuilder resources disappeared from the wait log.

---

One minor observation

In InitializeAsync at line 266, the fallback timeout error message still enumerates all resources from model.Resources (including IResourceWithoutLifetime ones):

var resourceNames = string.Join(", ", model.Resources.Select(r => $"'{r.Name}'"));

This is the catch block for custom WaitForResourcesAsync overrides, so it's rarely reached with the default implementation. But if a user is debugging an AllHealthy/AllRunning hang, seeing {name}-rebuilder in the timeout error could be confusing since the default path skips them. Consider using GetWaitableResourceNames(model) here too for consistency:

var waitableNames = GetWaitableResourceNames(model);
var resourceNames = string.Join(", ", waitableNames.Select(n => $"'{n}'"));

This is a nice-to-have, not a blocker — the fallback path is only reached when overriding WaitForResourcesAsync without the fail-fast helper.

---

Overall

The root cause fix is correct, the implementation is clean, and the change is minimal. The lazy-init pattern and correct exclusion of Named mode show good attention to detail. The observation above is minor. Approved.