Handle interaction service unimplemented and tests

[JamesNK]

Description

It's possible an app host doesn't implement the interaction service. We don't want the client to go into an infinite retry loop.

This change detects an unimplemented response from the server and stops the background task in the client watching for interactions.

Also, lots of tests.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[Copilot]

Pull Request Overview

This PR addresses an issue where the app host may not implement the interaction service, avoiding an infinite retry loop on the client side. Key changes include stopping background tasks when an unimplemented response is detected, refactoring the retry logic to use Task results, and adding new tests to verify this behavior.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
tests/Aspire.Dashboard.Tests/Model/DashboardClientTests.cs	Removed calls to SetInitialDataReceived and added a new test case with mock service client returning an Unimplemented status
src/Aspire.Dashboard/ServiceClient/DashboardClient.cs	Made _client internal for test injection, introduced TaskCompletionSources for watch completion, and updated watch methods with a bool return value to break retry loops when interactions are unimplemented

Comments suppressed due to low confidence (1)

src/Aspire.Dashboard/ServiceClient/DashboardClient.cs:516

• [nitpick] Add a clarifying comment near the try-catch block in IsUnimplemented to explain why catching InvalidOperationException is expected when the call is still in progress, ensuring future developers understand this design choice.

            var status = call.GetStatus();

[JamesNK]

Please review. I have more changes around this area and I'm going to start getting conflicts with multiple PRs parallel.

[eerhardt]

LGTM