Coordinate Project Resource v2 builds for file-based apps with shared project references

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

The Project Resource v2 plan in `docs/plans/project-v2-csharpprogram-watch.md` proposes a coordinated initial build by generating a temporary `.slnx` containing all `DotnetProjectResource` `.csproj` paths. Section 5.3 and Session 5 explicitly exclude file-based `.cs` apps, saying they will be "built/run individually."

File-based apps can reference traditional projects with `#:project`. If multiple file-based apps—or a file-based app and another project resource—reference the same class library and start concurrently, their individual `dotnet run --file` builds can write to the same `bin`/`obj` outputs concurrently and collide.

The existing `playground/DotnetProject` sample already demonstrates this scenario:

- `playground/DotnetProject/worker/worker.cs` contains `#:project ../../Playground.ServiceDefaults`.
- Both AppHosts currently chain `.WaitFor(...)`/`.waitFor(...)` across the project and file-based resources specifically to avoid shared build-output races.
- Their comments say to remove those waits once the coordinated `.slnx` build lands, but the proposed coordinator excludes the file-based app and therefore does not replace its build serialization.

The plan also does not explain how excluded file-based apps receive a coordinated initial build in watch mode, where the watch tool is described as performing incremental builds only.

### Describe the solution you'd like

Update the Project Resource v2 plan and coordinated-build design so file-based apps cannot concurrently build common referenced projects. The design should define how file-based app dependencies are discovered and coordinated, rather than simply excluding `.cs` resources from the build graph.

The implementation should ensure that:

- Multiple file-based apps referencing the same traditional project do not build that project concurrently.
- File-based apps and `.csproj` resources cannot concurrently build a shared dependency.
- Both watch and non-watch startup have a defined initial-build path for file-based apps.
- Removing the playground's temporary `.WaitFor(...)` serialization is safe.
- Tests cover at least two file-based apps sharing a `#:project` class-library reference and starting concurrently.

Possible approaches include incorporating discovered `#:project` dependencies into coordinated build planning, serializing file-based initial builds, or another build-graph-aware mechanism. The exact mechanism should preserve correct incremental and launch behavior for file-based apps.

### Additional context

Umbrella tracking issue: #16386

Watch tracking issue: #15710

Relevant plan sections: `docs/plans/project-v2-csharpprogram-watch.md` §5.3 and Sessions 5–6.