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.