Aspire crashed-executable diagnostics test times out with probe still Starting on Ubuntu #7555

Summary

The Aspire crashed-executable regression intermittently times out before its probe process starts on Ubuntu CI. It expects an InvalidOperationException from the nonzero process exit, but receives TimeoutException with the probe still Starting, so otherwise successful PR validation fails.

Reproduction

Run the .NET workflow on Ubuntu, which runs tests/TUnit.Aspire.Tests in Release/net10.0. Observed in run 41768003411, job 126370832367 on commit faaf396.

The failing test is CrashedExecutableLogTests.StartupDiagnostics_IncludeCrashedExecutableOutput in CrashedExecutableLogTests.cs. Its fixture starts dotnet --nonexistent-startup-probe with a never-healthy health check.

Expected and actual

Expected: the process exits nonzero, startup throws InvalidOperationException, and captured diagnostics contain its output.

Actual: after 60 seconds, the probe is still Starting (never reached Running); its only log is the certificate-authority setup message. Diagnostics also report the unrelated AppHost parameter my-secret as ValueMissing. The companion RetainedLogs_FollowRuntimeInstance_AndSurviveDisposal test passed in the same job; the Windows and macOS pipeline jobs passed. The PR only changes generic inference and fixtures, not Aspire code. No Aspire changes exist between its base 10a0af7 and current main 4891fce.

Environment

GitHub ubuntu-latest runner, .NET target net10.0, Aspire AppHost 13.6.4 (c89352703f78ae46de90fbf751ed8b52b77b89bf).

Please make the probe startup reliable and preserve the assertion that diagnostics include the crashed process output.

Acceptance criteria

• Diagnose why the executable can remain Starting and make the regression fixture reliably observe a real nonzero process exit on Ubuntu CI.
• Preserve the live diagnostic assertion for the crashed process marker and the retained-log assertion after disposal; do not accept a timeout as equivalent success.
• Validate both crashed-executable tests on Ubuntu and preserve Windows/macOS behavior.

Triage at main 4891fce71adee5d0d66e19c9fc20a367b9cca1e9: the fixture still uses a 60-second resource timeout and the same AppHost, which declares my-secret. The linked #7544 changes generic inference rather than Aspire startup; it does not deliver this fix.