.NET Aspire solutions can't build when their projects are in folders with source trees inclusive of other Aspire App Host/Defaults projects

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

The summary of this issue is that .NET projects that have already been orchestrated with Aspire can't be included in subsequent solutions orchestrated with Aspire unless the solution's `App Host` and `Defaults` projects are deleted or the project-to-be-included is moved into another directory. Whilst an edge case, this issue could be a manifestation of the "multi-repo scenario," or any multi-developer scenario in which:

1. one developer is primarily responsible for the orchestration (thus, the `App Host` and `Defaults` projects) and other developers build node projects (APIs, front end web apps, and so forth)
2. individual developers work on individual node projects without much consideration beyond their individual nodes for what's included in the `App Host` or `Defaults` projects, and they worry about it later during an integration phase of their release process

### Expected Behavior

When a developer is working on a .NET Aspire solution and they add a project to the solution that's in another .NET Aspire solution, the project references to the `Defaults` project is updated appropriately following orchestration and everything builds and runs once the project has been orchestrated into the destination .NET Aspire solution.

### Steps To Reproduce

This repro takes a Visual Studio approach, but the build exception is resident when replicating this process via the command line, too.

1. Create a new Aspire Starter App named `DestinationApp` at [for example] `c:\src\TheApp\DestinationApp\DestinationApp.sln` in a new instance of Visual Studio
2. Create a new Empter Aspire App named `NewIncomingAppNode` at [given example in step 1]: `c:\src\TheApp\NewIncomingAppNode\NewIncomingAppNode.csproj` in a second instance of Visual Studio
3. Add a new Web Api project named `TheApi` to the `NewIncomingAppNode` solution
4. Close the `NewIncomingAppNode` solution and go back to the `DestinationApp` solution's instance of Visual Studio
5. Add the `TheApi` project to the `DestinationApp` solution via the "Add -> Existing Project" menu in Visual Studio
6. Right-click `TheApi` project and "Add Aspire Orchestration" and note VS tells you it's going to use the `App Host` and `Defaults` project in the existing solution
7. Note the `TheApi` project has been added to the `App Host` project's `Program.cs`
8. You may need to edit the `TheApi.csproj` file if both `Defaults` projects have been added. You'd need to change:

```




```

into:

```



```

9. F5 the solution

### Exceptions (if any)

`Metadata file 'C:\src\TheApp\NewIncomingAppNode\NewIncomingAppNode.ServiceDefaults\obj\Debug\net9.0\ref\NewIncomingAppNode.ServiceDefaults.dll' could not be found`

### .NET Version info

```
.NET SDK:
Version: 9.0.200-preview.0.24611.4
Commit: 6d67e2a457
Workload version: 9.0.200-manifests.6448c051
MSBuild version: 17.13.0-preview-24569-04+8f6b8ad0a

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.200-preview.0.24611.4\

.NET workloads installed:
[aspire]
Installation Source: VS 17.13.35707.81, VS 17.13.35617.110
Manifest Version: 8.2.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.0
Architecture: x64
Commit: 9d5a6a9aa4

.NET SDKs installed:
9.0.200-preview.0.24575.35 [C:\Program Files\dotnet\sdk]
9.0.200-preview.0.24611.4 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
```

### Anything else?

To work around this issue, go to the `C:\src\TheApp\NewIncomingAppNode` folder and delete the `App Host` and `Defaults` projects. Then, rebuilding/running the `Destination` solution works. This is sub-optimal, as a developer working on the incoming app might prefer to work on their app in an isolated manner; they may have tests set up already, custom code in their `App Host` they're not finished testing, or anything else.