E2E tests: AspireRunReadyTimeout is applied to dotnet run sites where ASPIRE_CLI_START_TIMEOUT is never set, inverting its documented relationship

## Is there an existing issue for this?

Searched. #19255 is the closest, but it is about the CLI consuming the startup budget during restore and build. This is a separate, narrower thing in the E2E test helper. #18671 and its PR are where the constants below were introduced.

## Describe the bug

[`CliE2EAutomatorHelpers.cs:35-40`](https://github.com/microsoft/aspire/blob/7e4b8a7ee08ec29bc8fee159789f555cf8dc9fe3/tests/Aspire.Cli.EndToEnd.Tests/Helpers/CliE2EAutomatorHelpers.cs#L35-L40) documents `AspireRunReadyTimeout` as:

> Intentionally larger than `AspireRunStartupBudgetSeconds` so the CLI's own startup timeout fires (surfacing its diagnostic) before this wait gives up on a genuine hang.

That invariant holds only where the 180s budget is actually in effect, meaning where `ASPIRE_CLI_START_TIMEOUT=180` is passed via the `aspire run` shell prefix.

In [`BundleSmokeTests.cs`](https://github.com/microsoft/aspire/blob/7e4b8a7ee08ec29bc8fee159789f555cf8dc9fe3/tests/Aspire.Cli.EndToEnd.Tests/BundleSmokeTests.cs) three sites launch the AppHost with a bare `dotnet run` and no env prefix, then wait with `AspireRunReadyTimeout`:

| launch | wait |
|---|---|
| L91 `dotnet run --no-launch-profile --project ...` | L96 `AspireRunReadyTimeout` (240s) |
| L186 `dotnet run --no-launch-profile --project ...` | L191 same |
| L247 `dotnet run apphost.cs ...` | L252 same |

At those sites the governing budget is the CLI's built-in default, [`WaitCommand.DefaultTimeoutSeconds = 120`](https://github.com/microsoft/aspire/blob/7e4b8a7ee08ec29bc8fee159789f555cf8dc9fe3/src/Aspire.Cli/Commands/WaitCommand.cs#L31). So the documented ordering is inverted relative to intent: 240s of terminal wait sits above a 120s CLI budget that the constant was never applied to. In practice the CLI default still fires first, so this is not currently causing a wrong result. What it costs is the stated relationship between the two numbers, which is the thing a future reader will rely on when changing either one.

The awaited string (`"Press CTRL+C to stop the AppHost and exit."`) is CLI-emitted, so the bundle path is governed by that 120s default, which is the timeout #18671 set out to relax. On this path it is not relaxed.

It is also spreading. When I first read this (2026-08-11, at the #18671 PR) two sites had this shape. There are now three.

## Separately: four `aspire run` sites still run on the 120s default

These type a bare `aspire run` with no budget prefix, so the constant does not reach them and the cold-start flake #18671 targets is unmitigated:

| site | terminal wait |
|---|---|
| `JsReactTemplateTests.cs:36` | L49, 2 minutes |
| `JavaPolyglotTests.cs:70` | L72, 3 minutes |
| `TypeScriptPolyglotTests.cs:138` | L150, 3 minutes |
| `ConfigHealingTests.cs:69` | L71, 3 minutes |

`JsReactTemplateTests` is the sharpest of the four: its 2-minute terminal wait exactly equals the 120s CLI default, so the two timeouts race, and it adds an npm install to the cold path.

Whether these should adopt the budget is a judgement call about which suites are worth stabilising, so I am listing them rather than calling them bugs.

## Expected Behavior

Either the `dotnet run` sites get their own constant with a doc comment describing what actually governs them, or `AspireRunReadyTimeout`'s comment stops claiming a relationship to a budget that is not set on those paths.

## Steps To Reproduce

None. This is from reading the test sources at `7e4b8a7`, not from an observed failure.

---

_{Found while evaluating an AI code-review tool I maintain against merged agent-authored PRs. Hand-verified against upstream source before filing.}

Start with tests/Aspire.Cli.EndToEnd.Tests/Helpers/CliE2EAutomatorHelpers.cs and BundleSmokeTests.cs, then compare the timeout handling with src/Aspire.Cli/Commands/WaitCommand.cs. Review the three bare dotnet run sites and the separately listed aspire run sites, and run the relevant Aspire CLI end-to-end tests. Done means the documented timeout relationship is accurate on each affected path and the intended startup budget is applied or explicitly documented.

Written by the indexing model from the issue text.