Use crypto.randomUUID() for ActionCableLink channelId to prevent collisions

[obake-fe]

Summary

Replace the channelId generator in ActionCableLink to use crypto.randomUUID() so that simultaneously-created subscriptions no longer collide.

Fixes #5639.

Background

The previous channelId generator,

var channelId = Math.round(Date.now() + Math.random() * 100000).toString(16)

draws from only ~100,001 distinct values per millisecond. When multiple useSubscription hooks mount during the same render pass (or simply within a short time window), collisions are inevitable. With N subscriptions opened within ~100 seconds of each other, the collision probability is approximately C(N, 2) / 100_000 (e.g. ~0.05% for N=10, ~0.2% for N=20).

When two subscriptions share the same identifier:

1. The Rails ActionCable server deduplicates the second subscribe (return if subscriptions.key?(id_key) in action_cable/connection/subscriptions.rb).
2. The client retains both Subscription objects — ActionCable JS does not deduplicate.
3. On message arrival, ActionCable JS invokes received on all local subscriptions whose identifier matches.
4. The "deduplicated" (locally surviving) subscription's listener receives the other subscription's payload, which has the wrong shape, causing Apollo to log Missing field 'X' while writing result {...} warnings and downstream onData handlers to crash with TypeError.

Changes

• ActionCableLink.ts: replace the time+random channelId with crypto.randomUUID(). Add a short comment explaining why.
• __tests__/ActionCableLinkTest.ts: add a test that creates 1000 subscriptions in a tight loop and asserts the channelIds are all unique. With the old generator this would fail frequently (collisions are expected when many IDs are drawn within a single ms); with crypto.randomUUID() it always passes.

Compatibility

crypto.randomUUID() is available in:

• Chrome 92+ (July 2021)
• Firefox 95+ (December 2021)
• Safari 15.4+ (March 2022)
• Node 14.17+ / 16.7+ (and via globalThis.crypto in Node 19+)

If wider compatibility is required I'm happy to add a fallback (e.g. crypto.getRandomValues over a 128-bit buffer, or a module-scoped counter + Date.now).

Test plan

• npm test (full suite) passes locally — 92 passed / 3 skipped (unchanged from before)
• New test generates a unique channelId for each subscription passes

[rmosolgo]

Thanks again for taking this on.

wider compatibility

This is a good point -- I doubt anyone will need it, but I imagine a global crypto polyfill would work, too. I added a commit that also accepts an injected channelId: ... option, so if someone needs backwards compatibility (why??), they could acheive it.