fix(circuitbreaker): guard nil monitoring to prevent boot panic

Starting with ENABLE_CIRCUIT_BREAKER=true panicked at boot: parseConfig -> initCircuitBreaker registers a metrics gauge, but cfg.Monitoring is assigned later by StartMonitoringServer, so the registration dereferenced a nil *MetricsSetup.

Add nil-receiver guards to the MetricsSetup registration methods (RegisterMetricsGauge/GaugeFunc/Counter, RegisterFloatCounter, RegisterMetricsSummary/Histogram), matching their existing 'return a dummy to prevent panics' contract. The guard is a no-op for non-nil receivers, so existing callers are unaffected. The breaker and the admin dashboard (which reads gobreaker state directly) keep working.

Add regression tests for the nil-receiver methods and for initCircuitBreaker with nil monitoring.

monitoring/nil_safety_test.go

@@ -0,0 +1,25 @@
+package libpack_monitoring
+
+import (
+	"testing"
+
+	"github.com/stretchr/testify/require"
+)
+
+// TestRegistrationMethods_NilReceiver_NoPanic verifies that the metric
+// registration methods tolerate a nil *MetricsSetup receiver. Callers may
+// register metrics before the monitoring server has constructed the global
+// MetricsSetup (e.g. circuit breaker init during config parsing); these
+// methods must return a non-nil dummy instead of panicking.
+func TestRegistrationMethods_NilReceiver_NoPanic(t *testing.T) {
+	var ms *MetricsSetup // nil
+
+	require.NotPanics(t, func() {
+		require.NotNil(t, ms.RegisterMetricsGauge("g", nil, 1))
+		require.NotNil(t, ms.RegisterMetricsGaugeFunc("gf", nil, func() float64 { return 1 }))
+		require.NotNil(t, ms.RegisterMetricsCounter("c", nil))
+		require.NotNil(t, ms.RegisterFloatCounter("fc", nil))
+		require.NotNil(t, ms.RegisterMetricsSummary("s", nil))
+		require.NotNil(t, ms.RegisterMetricsHistogram("h", nil))
+	})
+}