rpc: investigate large amount of mutex contention in rpc.RemoteClockMonitor and VerifyClockOffset

During 25.4 scale testing, we noticed that mutex profiles from most nodes show that the total contention time summed across all goroutines is on the order of millions of seconds. The profile shows that the mutex in RemoteClockMonitor and related code is under heavy contention.

See attached files. These profiles were captured with no workload actively running.

- [mutex-profile.pb.gz](https://github.com/user-attachments/files/24194496/mutex-profile.pb.gz)
- [goroutine-profile.pb.gz](https://github.com/user-attachments/files/24194499/goroutine-profile.pb.gz)

One immediate question is: Can we change `GetOffset` to use `RLock()` instead of `Lock()`?

A slightly more involved question is: Can we replace this mutex with a `syncutil.Map`?

Jira issue: CRDB-57943

Start with RemoteClockMonitor, VerifyClockOffset, and GetOffset, then inspect the attached mutex-profile.pb.gz and goroutine-profile.pb.gz files to trace the contention. Compare the locking behavior with the proposed RLock and syncutil.Map approaches. Done means documenting the contention cause and determining whether either change is safe and effective.

Written by the indexing model from the issue text.