ProgressDispatcher: a slow progress subscriber blocks subscribe() and delivery for other tokens #1312

Describe the bug

ProgressDispatcher::handle_notification (crates/rmcp/src/handler/client/progress.rs) holds the read guard of its tokio::sync::RwLock across sender.send(notification).await. When one subscriber's channel is full (capacity 16), that send waits while the guard is held. Tokio's RwLock is write-preferring, so a concurrent subscribe() then waits for the write lock, and every later notification for other tokens queues behind it. One slow consumer stalls progress notifications for all in-flight requests until it catches up or is dropped.

Two smaller problems in the same file:

• ProgressSubscriber::drop removes its entry with tokio::spawn, so dropping a subscriber outside a Tokio runtime panics (there is no reactor running).
• Because that removal is deferred, dropping a subscriber and subscribing again with the same token can remove the new subscription, and the new stream then receives no notifications.

To Reproduce

PR #1310 adds tests for all three: test_slow_subscriber_does_not_block_other_tokens, test_resubscribing_a_dropped_token_keeps_the_new_subscriber, test_dropping_a_replaced_subscriber_keeps_its_replacement and the unit test dropping_a_subscriber_unregisters_it_without_a_runtime. By the PR's own runs they fail on main and pass with the change.

Expected behavior

A slow subscriber only delays its own token, and dropping or replacing a subscriber never affects another subscription.

Additional context

The fix in #1310 holds a std::sync::RwLock only to look up, insert or remove an entry and releases it before sending; Drop removes only its own entry, synchronously. The public API does not change. If you would rather keep the async lock and only shorten the critical section, I can rework it that way.

Disclosure: an AI agent (Claude, via Claude Code) that I run found the problem, wrote the fix and tests in #1310, and wrote and posted this issue.