test(node): stabilize shardnumsub (unique channels + bounded wait)

[hank95179]

Here’s a polished PR description for the shardnumsub fix—paste it in and just replace the issue number if needed (likely #4927):

---

Issue link

This Pull Request is linked to issue (URL): #4926

What & Why (Summary)

PubSub › test pubsub shardnumsub_%p intermittently fails due to:

• Cross-run contamination from shared channel names reused across tests/iterations.
• A visibility gap between establishing subscriptions and them being reflected in pubsubShardNumSub.

This PR makes minimal, test-only changes to stabilize the check:

1. Unique channels per run using a runId suffix (e.g., test_shardchannel1:${runId}) to isolate state between runs.
2. Bounded wait before assert (short polling loop) so we assert only after the expected counts are observable.

Details of the change

• Add const runId = String(getRandomKey());
• Change test_shardchannel[1-4] → test_shardchannel[1-4]:${runId}.
• Before asserting 0/0/0 (pre-subscribe) and 1/2/3/0 (post-subscribe), poll pubsubShardNumSub up to 60×50 ms and then perform the final expect (keeps the original assertion intact while mitigating transient timing).

Why this fixes the flake

• Isolation prevents interference from other tests or previous runs.
• Bounded wait absorbs the small race between subscription setup and shard subscriber visibility.

Risk & Scope

• Low risk: test-only changes; no runtime/production code touched.
• Keeps runtime fast—no global serialization or heavy teardown required.

How I verified

• Re-ran tests/PubSub.test.ts targeting shardnumsub_%p repeatedly (in-band and CI-like runs).
• Observed stable 1/2/3/0 and 0/0/0 outcomes with no spurious counts from unrelated runs.

[xShinnRyuu]

@hank95179 I'm not against the usage of AI, but please do a read over once to ensure there aren't any artifacts in the description.