Add runtime unit tests for generated TypeScript transport code (trackPromise/flushPendingPromises)

[davidfowl]

Summary

The TypeScript codegen pipeline (AtsTypeScriptCodeGenerator) has strong snapshot-based unit tests that verify the shape of generated code (73 tests). However, there are no runtime unit tests that execute the generated TypeScript logic — particularly the promise tracking and flushing infrastructure in transport.ts.

What's missing

The following runtime behaviors in src/Aspire.Hosting.CodeGeneration.TypeScript/Resources/transport.ts have no direct test coverage:

• trackPromise() — promises are added to the set and removed on settlement
• flushPendingPromises() — snapshot-based flush completes without deadlock when new promises are tracked mid-flush (e.g., by the build() PromiseImpl constructor)
• Error propagation — rejected promises are captured in _rejectedErrors and surfaced as AggregateError during flush
• Silent error loss — promises that reject before flush is called still have their errors collected

Why this matters

A deadlock bug in flushPendingPromises() (a while loop re-awaiting a promise tracked during flush) was caught only by code review, not by any test. The fix (snapshot-based single pass) is validated only by:

1. Snapshot tests — verify the generated code text matches, not that it runs correctly
2. E2E tests — aspire start would timeout on deadlock, but these are slow, Docker-dependent, and can't test subtle error handling

A targeted TypeScript unit test could deterministically reproduce the deadlock scenario and prevent regressions.

Suggested approach

Add a test file (e.g., transport.test.ts) that:

1. Instantiates the promise tracking logic directly
2. Tests trackPromise + flushPendingPromises with controlled promise resolution
3. Simulates the deadlock scenario: track a new promise while flush is suspended at await
4. Verifies AggregateError is thrown when tracked promises reject

Context

Related PR: #15901 (Auto-resolve promises in TypeScript codegen)