aspire-cli-4308c82b: aspire/cli/apphost.configure_isolated_mode 46a2dce took ~10s

## Summary

A startup profile captured from a PR dogfood build shows `aspire/cli/apphost.configure_isolated_mode` taking almost 10 seconds before the AppHost build starts.

The span in question:

- **Service instance:** `aspire-cli-4308c82b-b9ed-404b-be24-84645e1741ec`
- **Span:** `aspire/cli/apphost.configure_isolated_mode`
- **Span ID:** `46a2dcec8b430444`
- **Duration:** `9993.866 ms`
- **Parent:** `aspire/cli/apphost.run`
- **Child:** `process dotnet`, duration `9990.851 ms`

## What the child process did

The child `dotnet` process under `configure_isolated_mode` was an AppHost info/MSBuild probe:

```text
dotnet build \
-getProperty:MSBuildVersion,IsAspireHost,AspireHostingSDKVersion,AspireUseCliBundle,UserSecretsId,RunCommand,TargetPath,RunWorkingDirectory,RunArguments,TargetFramework,TargetFrameworks \
-getItem:PackageReference,AspireProjectOrPackageReference,PackageVersion \
-t:ComputeRunArguments \
/var/folders/.../ProfileApp/apphost.cs
```

Trace attributes reported:

```text
aspire.cli.dotnet.command = build
aspire.cli.dotnet.project_file = /var/folders/.../ProfileApp/apphost.cs
aspire.cli.dotnet.stdout_lines = 20
process.exit.code = 0
```

## Why this seems suspicious

`configure_isolated_mode` only needs to enable randomized ports and determine/copy user secrets. It currently calls into AppHost info resolution to get `UserSecretsId`; on a cold cache this performs the MSBuild/AppHost info probe before the actual AppHost build.

In the same trace, the subsequent real build still ran separately:

```text
aspire/cli/apphost.configure_isolated_mode 9993.866 ms
process dotnet 9990.851 ms
aspire/cli/apphost.ensure_dev_certificates 341.786 ms
aspire/cli/apphost.build 8119.477 ms
process dotnet 8119.143 ms
```

So a cold isolated-mode start paid for both:

1. A ~10s AppHost info/MSBuild probe to configure isolated mode.
2. A separate ~8.1s AppHost build.

## Cache note

The code path appears to use the Aspire CLI AppHost info cache (`AppHostInfoResolver` / `AppHostInfoDiskCache`), but this trace was from a fresh temp app so the disk cache was cold. The presence of the child `process dotnet` span under `configure_isolated_mode` indicates the cache did not satisfy this run.

If the AppHost info is needed for isolated mode, it may be worth investigating whether the probe can be avoided, deferred, shared with the later build, or made cheaper for file-based AppHosts.

## Profile context

Captured with `aspire start --isolated --capture-profile` against a fresh `aspire-empty` file-based AppHost from PR dogfood build `13.4.0-pr.17449.ge78584ba`.

The profile also showed the DCP certificate span working as expected; this issue is specifically about the `configure_isolated_mode` span duration.

Start at aspire/cli/apphost.configure_isolated_mode and trace its use of AppHostInfoResolver and AppHostInfoDiskCache; compare the cold-cache probe with the later AppHost build. Verify a change avoids, defers, shares, or reduces the probe while still configuring randomized ports and user secrets, then confirm the profile no longer pays for redundant work.

Written by the indexing model from the issue text.