This PR addresses #55610 by updating CacheSchedulingMutex to use the lock connection instead of the default cache connection when acquiring a mutex. This mirrors the existing behavior of CacheEventMutex and ensures consistency.

To maintain API compatibility, I replicated the locking logic used in CacheEventMutex.

In our production environment, the default cache connection is not using the same instance for all servers, while the lock connection is. As described in the referenced issue, this leads to race conditions unless a workaround (defining a separate store) is implemented. The current behavior is unintuitive and, in my view, should be corrected even though a workaround exists.

Considerations

• The main trade-off is a small amount of code duplication.
• The change remains fully backwards compatible:
  • The keys used to acquire the locks are unchanged between the current and proposed implementations.
  • This only affects users who have configured a separate lock connection and are running multiple application versions concurrently. In that edge case, commands may run on multiple servers, depending on how connections are set up.