[fix][test] Make KeyShared draining-hashes delivery test deterministic

[Dream95]

Fixes #26568

Main Issue: #xyz

PIP: #xyz

Motivation

CI fails in KeySharedSubscriptionTest.resetDefaultNamespace with:
Topic has 8005 clients connected Including 8004 consumers, 0 producers, and 0 replicators.

Example: https://github.com/apache/pulsar/actions/runs/34130276934/job/101987362625

The leftover clients come from testMessageDeliveredFromDrainingHashes. That test used addConsumersUntilOwnerChanged, which kept creating Key_Shared consumers until consistent hashing moved testMessageKey off the original owner.
With subscriptionKeySharedConsistentHashingReplicaPoints=100 and a large hash space, a randomly named consumer often does not steal that hash. The loop can create thousands of consumers (8004 in the failure). The test then cannot finish cleanup before @AfterMethod, so resetDefaultNamespace cannot delete the topic.

Modifications

Replace addConsumersUntilOwnerChanged with addConsumerThatTakesOverHash. It picks a consumer name (takeover-N) that will own the target hash, subscribes that one consumer, and fails if the owner did not change.
findConsumerNameThatTakesHash builds a local ConsistentHashingStickyKeyConsumerSelector with the live replica-point count and selector.getKeyHashRange().getEnd().
Cleanup only has that extra consumer to close. findOwnerName uses selector.select(hash).

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests, such asKeySharedSubscriptionTest.testMessageDeliveredFromDrainingHashes.
Ran that method locally 500 times. All passed.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment