RedisTokenManager can assign the same client token to two sockets under concurrency

[anxkhn]

Description

RedisTokenManager.link_token_to_sid used a non-atomic check-then-set against Redis (EXISTS then SET). Under concurrent workers, two connections can both observe an absent token and then store different socket records for it, so two sockets share the same client token/state.

Expected Behavior

Only one worker should successfully claim a given token. A losing worker should get a new token (or a safe local fallback if Redis is unavailable).

Actual Behavior

Two workers can both link the same token to different SIDs when the claims race.

Steps to Reproduce

1. Run multiple app workers backed by the same Redis instance.
2. Have two clients connect around the same time with a token that is not yet present in Redis.
3. Observe both workers treating the token as newly claimable.

Proposed Fix

Claim tokens with an atomic Redis SET using NX (and the existing TTL). Retry with a new UUID if the claim loses; keep the local token-manager fallback on Redis errors.

Tracked in #6771

[linear-code]

ENG-11138