fix: keep one subscription when first subscribes race

[boks1971]

Find or create a track subscription and set it as desired under one lock.

SubscribeToTrack looked up the subscription, and if there was none, it created one and stored it under a separate lock. SubscribeToDataTrack did the same. Two first subscribes that ran at the same time could each store their own entry, and the second one replaced the first.

The replaced entry could still be reconciled and add a down track. After that, nothing owned the down track, and the kept entry tried to subscribe again. A settings update that ran at the same time could also put the settings on the replaced entry, so the down track never got them.

Now the lookup, the create and setDesired(true) run under one m.lock. This also stops the cleanup pass from removing a new entry before it is marked as desired. The lock order is the same as before (manager lock, then subscription lock).

TestConcurrentFirstSubscribe runs two subscribes and one settings update at the same time, 200 times. It checks that the kept subscription owns the down track and that the down track got the settings. On master it fails within the 200 rounds.

Two more cases are fixed in the same code:

• A settings or options update before the first subscribe creates an entry that is not desired. Cleanup removed that entry on its next pass, so the subscribe made a new entry without the settings. The entry is now kept for notFoundTimeout (1 minute) after the update.
• After a data track unsubscribe, the entry was deleted even if a subscribe set it as desired during the removal, and the client stayed unsubscribed. It is now deleted only if it is still not desired, and otherwise it is reconciled again.

Cleanup also deletes only the entry that it checked. TestSettingsKeptForSubscribe and the "subscribe again during unsubscribe" case in TestSubscribeDataTrack fail on master.

🤖 Generated with Claude Code