The MAUI SDK's Run target does not depend on Build, so using just
/t:Run skipped the build step entirely. Mac Catalyst failed because
the .app bundle didn't exist when 'open' tried to launch it, and
iOS failed with 'app must be built before launch args can be computed'.

Using /t:Build;Run ensures the Build target runs first, then the Run
target launches the app. This also has the benefit of keeping the
process alive (Mac Catalyst uses 'open -W', iOS uses 'mlaunch
--wait-for-exit:true'), so resources show as Running instead of
immediately going to Finished.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

MAUI uses single-project architecture where multiple platform resources
(Android, iOS, Mac Catalyst, Windows) can reference the same .csproj.
MSBuild cannot handle concurrent builds of the same project file.

This adds a SemaphoreSlim-based build queue that:
- Serializes builds per-project using MauiBuildQueueAnnotation
- Shows 'Queued' state in the dashboard while waiting
- Releases the semaphore when a resource reaches a terminal state
- Handles cancellation and failure gracefully

The annotation is added eagerly in AddMauiProject() to avoid race
conditions when multiple platform resources start concurrently.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Two improvements to the MAUI build queue:

1. Show 'Building' state in dashboard when a resource acquires the
   build lock, so users see Building → Running instead of immediately
   Running while MSBuild is still compiling.

2. Release the semaphore when a resource reaches 'Running' state
   (not just terminal states). iOS and Mac Catalyst stay Running
   indefinitely after launch, so waiting for terminal states would
   block the queue until the user manually stops the app.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The previous approach released the semaphore when the resource reached
'Running' state, but DCP sets Running immediately when the process
starts — while MSBuild is still compiling. This caused the queue to
release too early, allowing concurrent builds.

Now the subscriber watches the resource's log stream for MSBuild
completion output ('Build succeeded' or 'Build FAILED') to detect
when the build phase actually finishes. A terminal state fallback
ensures the semaphore is always released if the process exits before
producing build output.

Also shows 'Building' state in the dashboard while MSBuild compiles,
giving users clear visibility into: Queued → Building → Running.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Instead of relying on log output parsing to detect when MSBuild
finishes, run 'dotnet build' as a separate subprocess during
BeforeResourceStartedEvent. This provides:

- Reliable exit-code-based build completion detection (0 = success)
- 'Building' state persists in the dashboard for the entire build
  (the event handler blocks DCP from starting the process)
- Clean separation: Build runs in event handler, DCP only runs /t:Run

The MauiBuildQueueEventSubscriber now spawns a 'dotnet build' process,
pipes its stdout/stderr to the resource logger (visible in dashboard),
and uses the exit code to determine success or failure. The semaphore
is released in a finally block, ensuring the queue always progresses.

MauiPlatformHelper now sets /t:Run (not /t:Build;Run) since the Build
target is handled by the event subscriber. A MauiBuildInfoAnnotation
carries the project path, TFM, and working directory to the subscriber.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fix #1: Drain stdout/stderr tasks in a finally block so they are
always awaited, even when WaitForExitAsync throws on cancellation.
PipeOutputAsync now catches OperationCanceledException internally.

Fix #2: Resolve build configuration from the AppHost's
AssemblyConfigurationAttribute (same as DcpExecutor) and pass it to
MauiBuildInfoAnnotation, so the pre-build and DCP's Run target use
the same configuration and MSBuild's incremental build is effective.

Fix #3: Add 10-minute build timeout via CancellationTokenSource so
a hung dotnet build process cannot block the semaphore forever.
BuildTimeout is an internal settable property for testability.

Fix #4: Add tests for MauiBuildInfoAnnotation (properties, nullable),
missing MauiBuildQueueAnnotation (skip), resource restart (build same
resource twice), and unexpected exception types (semaphore release).

Total: 90 tests passing (18 build queue + 72 existing).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fix #1: Move _buildCompletions.TryRemove into finally block in
TestableBuildQueueSubscriber so cancelled/failed builds clean up
their TCS entries, preventing stale entries on resource restart.

Fix #3: Add MissingBuildInfoAnnotation_SkipsBuildAndReleasesQueue
test that uses the real MauiBuildQueueEventSubscriber to verify the
RunBuildAsync warning-and-skip path when MauiBuildInfoAnnotation is
absent, and confirms the semaphore is properly released.

Fix #5: Remove IDisposable from MauiBuildQueueAnnotation — no other
annotation in Aspire implements IDisposable and the semaphore is
garbage-collected on app shutdown. Remove the Dispose test.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fix test issues found in third review pass:

- ThreeResources_ExecuteInSequence now asserts actual execution order
  (android → maccatalyst → ios), not just completion counts
- SecondResource_ShowsQueuedState and SingleResource_ShowsBuildingState
  now properly await all event tasks before test cleanup
- ResourcesFromDifferentProjects_RunConcurrently now verifies both
  tasks are actively building simultaneously (not pre-completed)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The root cause was timing: WithCommand in MauiPlatformHelper ran at app
model build time, but the default lifecycle commands (start/stop/restart)
are added later by DcpExecutor.EnsureRequiredAnnotations. This caused
duplicate stop command annotations, making SingleOrDefault return null
and the stop button to fail with 'command not available'.

Fix: Move the stop command replacement into BeforeResourceStartedEvent
handler in MauiBuildQueueEventSubscriber, which fires AFTER DcpExecutor
has added the lifecycle commands. Key changes:

- EnsureStopCommandReplaced() in subscriber replaces the default stop
  command annotation with one that calls CancelResource for Queued/Building
  and delegates to the original for Running state
- MauiStopCommandReplacedAnnotation marker prevents double replacement
- CancelResource() on MauiBuildQueueAnnotation with ConcurrentDictionary
  for per-resource CTS tracking
- Graceful cancellation: catches OCE from our CTS, sets Exited state
- semaphoreAcquired flag for correct semaphore release
- Removed WithCommand from MauiPlatformHelper (was running too early)
- 3 tests: cancel queued, cancel building, next proceeds after cancel

93 tests passing.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Fix two bugs in the MAUI build queue stop command:

1. Resource name mismatch: The stop command used context.ResourceName
   (DCP-resolved name like 'mauiapp-maccatalyst-vqfdyejk') but the CTS
   dictionary is keyed by resource.Name (model name 'mauiapp-maccatalyst').

2. OCE swallowing: The catch block swallowed OperationCanceledException
   instead of re-throwing, causing DCP to proceed with CreateExecutableAsync
   and start the resource despite cancellation.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- Add stateAtCallTime parameter to ReleaseSemaphoreAfterLaunchAsync to
  skip the replayed snapshot from WatchAsync on resource restart, preventing
  premature semaphore release from stale state matches.
- Implement IDisposable on MauiBuildQueueAnnotation to properly dispose
  the SemaphoreSlim when the annotation is cleaned up.
- Document why 'Running' in the predicate is acceptable (pre-build already
  compiled; dotnet build /t:Run only does fast incremental check).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>