aspire ps cannot discover AppHosts started outside a Windows sandbox because backchannel discovery is tied to UserProfile

### Is there an existing issue for this?

- [x] I have searched the existing issues

I found some Windows backchannel/socket issues such as #17441 and #17587, but those appear to be about stale/refused sockets during `aspire add`/`aspire stop`. This report is specifically about Windows sandbox/user-profile isolation causing `aspire ps` to scan the wrong backchannel directory.

### Describe the bug

On Windows, `aspire ps` discovers running AppHosts by scanning the auxiliary backchannel sockets under the current process user profile, currently:

```text
%UserProfile%\.aspire\cli\bch
```

That breaks when the AppHost and the CLI command are run under different Windows identities, which is common for sandboxed agent environments. In that setup, the AppHost is running and visible as an OS process, but `aspire ps` reports no running AppHost because it scans the sandbox user's profile rather than the interactive user's profile where the AppHost created its socket.

Concrete example from a native Windows Codex environment:

- The AppHost was started from the normal user account, `patrick`.
- A sandboxed agent shell ran `aspire ps` under the Windows sandbox identity `CodexSandboxOffline`.
- The AppHost process and CLI parent were visible from the sandboxed shell:

```text
13664 Cantaro.AppHost
13324 aspire
```

But sandboxed `aspire ps` returned:

```text
Scanning for running AppHosts...
No running AppHost found. Use 'aspire run' to start one first.
```

With trace logging, the sandboxed CLI wrote logs under the sandbox profile:

```text
C:\Users\CodexSandboxOffline\.aspire\logs\...
```

The live AppHost socket existed under the real user profile instead:

```text
C:\Users\patrick\.aspire\cli\bch\042Aw9dkWWony7dNuBV.13664
```

Running the same command outside the sandbox succeeded immediately and found the AppHost:

```json
[
{
"appHostPath": "D:\\opensource\\Cantaro\\src\\Cantaro.AppHost\\Cantaro.AppHost.csproj",
"appHostPid": 13664,
"status": "running",
"sdkVersion": "13.5.0-preview.1.26306.1",
"cliPid": 13324,
"dashboardUrl": "https://localhost:17156/login?t=...",
"logFilePath": "C:\\Users\\patrick\\.aspire\\logs\\cli_...detach-child_....log"
}
]
```

### Expected Behavior

`aspire ps` should be able to discover a running in-scope AppHost even when the command is run from a sandboxed Windows process whose `Environment.SpecialFolder.UserProfile` differs from the AppHost's user profile, or Aspire should provide a supported configuration/environment override for the backchannel root.

At minimum, the failure mode should make it clear that Aspire scanned a different profile's backchannel directory.

### Steps To Reproduce

1. On Windows, start an Aspire AppHost from a normal interactive user account:

```powershell
aspire start
```

2. Confirm from the same user shell that `aspire ps` sees it.

3. Run `aspire ps` from a Windows sandboxed process that uses a different Windows identity/profile but can still see the AppHost process. For example, native Windows Codex with the elevated sandbox runs shell commands as a dedicated lower-privilege sandbox user.

4. Observe that `aspire ps` reports no running AppHost.

5. Compare identity/profile resolution inside the sandboxed command:

```powershell
[System.Environment]::UserName
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
[System.Environment]::GetFolderPath('UserProfile')
[System.Environment]::GetFolderPath('LocalApplicationData')
[System.Environment]::GetFolderPath('ApplicationData')
```

In the observed Codex case, this returned:

```text
CodexSandboxOffline
\CodexSandboxOffline
C:\Users\CodexSandboxOffline
C:\Users\patrick\AppData\Local
C:\Users\patrick\AppData\Roaming
```

6. Run the same `aspire ps --format Json --log-level Trace --non-interactive` outside the sandbox and observe that it finds the AppHost.

### Exceptions (if any)

No exception is shown. The command exits successfully with an empty result / no running AppHost found.

### Aspire doctor output

```log
Aspire Environment Check
========================

Aspire
✅ Aspire CLI version 13.5.0-preview.1.26306.1 (channel: daily)

AppHost
⚠️ Could not determine AppHost version (src\Cantaro.AppHost\Cantaro.AppHost.csproj)

.NET SDK
✅ .NET 11.0.100-preview.2.26159.112 installed (x64)

Container Runtime
⚠️ Docker: installed but not running ← active
Start Docker daemon

Environment
⚠️ HTTPS development certificate is not trusted
Run 'aspire certs trust' to trust the HTTPS development certificate.
See: https://aka.ms/aspire-prerequisites#dev-certs
Details:
Certificate C2EBB8EFA3F9F00D7401557C6DAD9282867AB3CE exists in the personal store but was not found in the trusted root store.

Summary: 2 passed, 3 warnings, 0 failed
For detailed prerequisites: https://aka.ms/aspire-prerequisites

Aspire CLI Installations
========================

Path: C:\Users\patrick\.aspire\bin\aspire.exe (current)
Version: 13.5.0-preview.1.26306.1+2de7be885e0ecdc531ab000048beb16e00a08335
Channel: daily
Route: (unknown)
PATH status: active
```

### Anything else?

This appears to come from both sides of the auxiliary backchannel using `Environment.GetFolderPath(Environment.SpecialFolder.UserProfile)` as the namespace root:

- `Aspire.Cli.Backchannel.AuxiliaryBackchannelMonitor` computes `_backchannelsDirectory` from `BackchannelConstants.GetBackchannelsDirectory(GetHomeDirectory())`, and `GetHomeDirectory()` returns `Environment.SpecialFolder.UserProfile`.
- `Aspire.Hosting.Backchannel.AuxiliaryBackchannelService` computes the AppHost socket path using `Environment.SpecialFolder.UserProfile` and `BackchannelConstants.ComputeSocketPath(...)`.
- `BackchannelConstants.GetBackchannelsDirectory(...)` maps that home directory to `.aspire\cli\bch`.

This makes the backchannel discovery namespace depend on the process identity rather than the project, actual AppHost owner, or an explicit shared Aspire home/backchannel setting.

From a Windows point of view, this is likely to affect any agent or automation tool that uses a separate Windows sandbox identity. It also makes Aspire harder to use from Codex on Windows, because Codex's native elevated sandbox intentionally runs commands as a dedicated lower-privilege sandbox user. A Codex user can currently work around it by running Aspire commands outside the sandbox or using a less isolated/full-access configuration, but that weakens the normal safety model for local agent workflows.

Possible fixes:

- Add a supported environment/config override for the Aspire backchannel root, used consistently by both CLI and AppHost.
- Consider whether backchannel discovery should use a location based on `LocalApplicationData`/`ApplicationData` or another Windows location that is stable across restricted tokens/sandbox users when appropriate.
- Improve diagnostics in `aspire ps` to log/display the scanned backchannel directories when no AppHosts are found, especially on Windows.