Fix StartupFormResourceAnnotation resolved at registration time instead of evaluation time

[Copilot]

WithProjectCommands captured StartupFormResourceAnnotation once at call time, meaning if WithProjectManifest was called afterward, the annotation would never be found and commands would stay permanently enabled regardless of form completion state.

Changes

• ResourceBuilderProjectCommanderExtensions.cs: Removed the upfront annotation lookup; moved it inside the UpdateState delegate so it resolves from builder.Resource.Annotations on every state evaluation

// Before: annotation captured once at registration — misses later-added annotations
var startupFormAnnotation = builder.Resource.Annotations
    .OfType<StartupFormResourceAnnotation>()
    .FirstOrDefault();

UpdateState = startupFormAnnotation != null
    ? _ => startupFormAnnotation.StartupFormResource.IsCompleted
        ? ResourceCommandState.Enabled
        : ResourceCommandState.Disabled
    : null

// After: resolved dynamically — call order between WithProjectCommands / WithProjectManifest no longer matters
UpdateState = _ =>
{
    var annotation = builder.Resource.Annotations
        .OfType<StartupFormResourceAnnotation>()
        .FirstOrDefault();
    return annotation != null && !annotation.StartupFormResource.IsCompleted
        ? ResourceCommandState.Disabled
        : ResourceCommandState.Enabled;
}

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes a timing issue where StartupFormResourceAnnotation was captured at registration time in WithProjectCommands, causing commands to remain permanently enabled when WithProjectManifest (which adds the annotation) was called after WithProjectCommands. The fix resolves the annotation dynamically on each state evaluation, making the call order between these methods irrelevant.

Changes:

• Modified WithProjectCommands to resolve StartupFormResourceAnnotation dynamically in the UpdateState callback instead of capturing it once at registration time
• Commands now correctly check form completion state regardless of whether WithProjectCommands or WithProjectManifest is called first

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This change modifies the core behavior of command state management based on startup forms, but there are no tests covering this logic. Consider adding tests that verify commands are disabled when a startup form exists and is incomplete, enabled when the form is completed, and that the annotation is resolved dynamically to handle different call orders of WithProjectCommands and WithProjectManifest.

[Copilot]

The new logic always provides an UpdateState function, whereas the old code set UpdateState to null when no StartupFormResourceAnnotation existed at registration time. While the new behavior correctly handles dynamic annotation resolution (the main fix), it also means commands without startup forms now have their state explicitly managed to return Enabled on every check, rather than having no UpdateState callback. Verify this behavior change is intentional and doesn't have unintended side effects in the Aspire framework's command state management.