Fix ClusterClientDiscovery: preserve contact-point subscriptions across rediscovery

[Aaronontheweb]

Closes #8425.

Problem

With initial-contacts discovery enabled, ClusterClientDiscovery supervises the real ClusterClient as a child and recreates that child from scratch on every rediscovery (when the current child exhausts its reconnect-timeout and stops). The contact-point subscriber list lives on the child, and the supervisor kept no record of it — so a SubscribeContactPoints subscriber silently stopped receiving ContactPoints / ContactPointAdded / ContactPointRemoved events once the client rediscovered. GetContactPoints was unaffected (the supervisor forwards each query to the current child); only the durable subscription was dropped.

Fix

ClusterClientDiscovery now tracks contact-point subscribers at the supervisor level and re-establishes them on each newly-created child:

• SubscribeContactPoints / UnsubscribeContactPoints are recorded in a supervisor-level subscriber set (and DeathWatched, so a terminated subscriber is dropped — auto-unsubscribe), then still forwarded to the current child so live behavior is unchanged.
• When a new child is created on rediscovery, the supervisor re-sends SubscribeContactPoints on each tracked subscriber's behalf, so the child registers them and replies with the current snapshot.

No public API change; internal supervisor behavior only.

Testing

ClusterClientDiscoverySpec is reworked to verify contact points through the client's own subscription event stream (SubscribeContactPoints → ContactPoints/ContactPointAdded/ContactPointRemoved) instead of polling GetContactPoints. Its second and third phases exercise rediscovery after a graceful down and a hard shutdown, so the subscription must survive the child being recreated for the test to observe the new node — i.e. the spec both de-flakes the old orphaned inner-timeout poll and directly covers this fix. Verified locally, 4/4 across repeated runs.