Fix deadlock in ServiceEndpointWatcher when disposing change token registration

[ReubenBond]

Summary

Fixes a deadlock in ServiceEndpointWatcher that occurs when disposing the change token registration while holding _lock.

The Problem

A deadlock can occur with the following sequence:

1. Thread A enters RefreshAsyncInternal(), acquires _lock, and calls _changeTokenRegistration?.Dispose()
2. CancellationTokenRegistration.Dispose() blocks waiting for any in-flight callback to complete
3. Thread B is executing the change token callback which calls RefreshAsync(force: false), which tries to acquire _lock
4. Deadlock: Thread A holds _lock and waits for Thread B's callback → Thread B waits for _lock held by Thread A

The Fix

Move _changeTokenRegistration?.Dispose() outside the lock:

• Capture the registration reference while holding the lock
• Set the field to null while holding the lock
• Dispose outside the lock

Applied to both RefreshAsyncInternal() and DisposeAsync() methods.

Testing

• All existing ServiceDiscovery tests pass (50/50)

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull request overview

This PR fixes a critical deadlock issue in ServiceEndpointWatcher that occurs when disposing change token registrations while holding a lock. The deadlock happens when one thread holds the lock and waits for a callback to complete, while the callback thread is blocked trying to acquire the same lock.

Changes:

• Moved _changeTokenRegistration?.Dispose() outside the lock in RefreshAsyncInternal() by capturing the registration before disposal
• Applied the same pattern to DisposeAsync() for both _changeTokenRegistration and _pollingTimer
• Added explanatory comments documenting the deadlock scenario and why disposal must occur outside the lock

[rzikm]

LGTM, modulo one comment

[joperezr]

/backport to release/10.2

[github-actions]

Started backporting to release/10.2: https://github.com/dotnet/extensions/actions/runs/21645137209

[github-actions]

@joperezr backporting to "release/10.2" failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Patch format detection failed.
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[ReubenBond]

/backport to release/10.2

[github-actions]

Started backporting to release/10.2: https://github.com/dotnet/extensions/actions/runs/21650268580