Don't subscribe to dynamic config until partition manager Start, fixing loser-of-load-race leak

[harrisleesh]

What changed?

newTaskQueuePartitionManager (and newRateLimitManager) now only allocate: the rate limit manager's dynamic config subscriptions are registered in Start instead of at construction time.

With that, the loser of the double-checked race in getTaskQueuePartitionManager (constructed, but never started or published) holds no external references and can simply be dropped and garbage collected — no special cleanup path needed.

Why?

Fixes #11051.

The full partition manager graph is constructed before taking the write lock. When the constructor lost the race, the abandoned manager stayed reachable from the dynamic config collection forever via the subscriptions newRateLimitManager registered at construction time, so it was never garbage collected.

Any repeated partition unload with user-data pollers attached triggers this: when a partition unloads, the returning GetTaskQueueUserData long-polls from child partitions and sticky queues race to re-create it, and every reload could strand one or more losers (~55 KB each). In the deployment where this was found, lease contention unloaded every system task queue roughly every 30s, producing unbounded matching heap growth (~50 MB/h with no workflow traffic) ending in OOM — but healthy clusters hit the same race whenever partition ownership moves (rolling deploys, scaling matching nodes). See the issue for heap profile diffs and the full root cause analysis.

How did you test it?

• built
• added new unit test(s)

TestConstructionDoesNotRegisterDynamicConfigSubscriptions verifies that construction registers no dynamic config subscriptions, and that Start/Stop register and release them. Existing tests that construct a rateLimitManager directly now call Start on it, matching the production lifecycle. Passes in all three suite variants (Classic/Pri/Fair). The leak itself was diagnosed from production heap profile diffs (growth signature rooted at newTaskQueuePartitionManager under the GetTaskQueueUserData handler, pinned via dynamicconfig.subscribe[...]), matching exactly the loser path.

Potential risks

Rate limits are now initialized in Start rather than at construction. The manager is only published to the partitions map immediately before Start, and all dispatch/poll paths gate on defaultQueueFuture, which is only set by initialize (spawned at the end of Start), so no path can observe the rate limit manager before its subscriptions are registered.

[CLAassistant]

All committers have signed the CLA.

[dnr]

Instead of making the lifecycle more complicated by making the "initialized but not started" state require special transitions, how about we just avoid doing anything besides allocation in newTaskQueuePartitionManager, and not subscribing to dynamic config until Start()?

[harrisleesh]

@dnr
Done in 964d896. newRateLimitManager now only allocates; the dynamic config subscriptions moved to a new rateLimitManager.Start, called from taskQueuePartitionManager.Start before the initialize goroutine is spawned. closeUnstarted is gone — the loser of the load race is just dropped and garbage collected.

Ordering note: the manager is only published to the partitions map right before Start, and dispatch/poll paths gate on defaultQueueFuture (set by initialize), so nothing can observe the rate limit manager before its subscriptions are registered.

Tests that construct a rateLimitManager directly now call Start on it, and I updated the PR title/description to match the new approach.