Please address the comments from this code review:

## Individual Comments

### Comment 1
<location> `central/metrics/custom/tracker/tracker_base.go:137-143` </location>
<code_context>
 	}
-	previous := tracker.setConfiguration(cfg)
+
+	tracker.metricsConfigMux.Lock()
+	defer tracker.metricsConfigMux.Unlock()
+	previous := tracker.config
+	tracker.config = cfg
+
 	if previous != nil {
-		if cfg.period == 0 {
+		if !tracker.isEnabledNoLock() {
 			log.Debugf("Metrics collection has been disabled for %s", tracker.description)
 			tracker.unregisterMetrics(slices.Collect(maps.Keys(previous.metrics)))
</code_context>

<issue_to_address>
**issue (bug_risk):** Avoid holding metricsConfigMux while performing potentially heavy unregisterMetrics work

With the new `defer tracker.metricsConfigMux.Unlock()`, `unregisterMetrics` now runs while `metricsConfigMux` is held, whereas previously it executed after the lock was released. If `unregisterMetrics` is expensive or calls code that (directly or indirectly) takes this mutex, this can cause high contention or deadlocks. Please narrow the critical section to just updating/reading `tracker.config` (e.g., compute `previous` and whether metrics are disabled under the lock, then release it before calling `unregisterMetrics`).
</issue_to_address>