fix: Initialize peer metrics on startup to fix restart gap

[KA-ROM]

Overview

After service restarts, peer count metrics are empty until the first successful monitoring tick. This causes empty gaps in observability despite bmonitor being healthy. This PR fixes that by initializing peer metrics to 0 for all configured builder × peer label combinations on startup.

[Copilot]

Pull request overview

Initializes peer-count metrics at server startup so dashboards don’t show empty gaps after a restart (before the first monitoring tick).

Changes:

• Adds a startup hook to pre-record PeersCount = 0 for each configured builder and peer label.
• Introduces OTel metric attribute imports used for metric initialization.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Prefer the typed helpers (e.g., attribute.String(\"builder\", builder)) over manually constructing attribute.KeyValue with attribute.StringValue(...). It reads clearer and avoids potential subtle inconsistencies in how attributes are constructed across the codebase.

Suggested change

	attribute.KeyValue{Key: "builder", Value: attribute.StringValue(builder)},
	attribute.KeyValue{Key: "type", Value: attribute.StringValue(typ)},
	))
	}
	for _, label := range s.peers {
	metrics.PeersCount.Record(ctx, 0, otelapi.WithAttributes(
	attribute.KeyValue{Key: "builder", Value: attribute.StringValue(builder)},
	attribute.KeyValue{Key: "type", Value: attribute.StringValue("labelled")},
	attribute.KeyValue{Key: "label", Value: attribute.StringValue(label)},
	attribute.String("builder", builder),
	attribute.String("type", typ),
	))
	}
	for _, label := range s.peers {
	metrics.PeersCount.Record(ctx, 0, otelapi.WithAttributes(
	attribute.String("builder", builder),
	attribute.String("type", "labelled"),
	attribute.String("label", label),

[Copilot]

This introduces several magic strings for attribute keys/values (\"builder\", \"type\", \"label\", \"loopback\", \"internal\", \"external\", \"labelled\"). Consider centralizing these as constants (or reusing existing constants/enums if the repo has them) to prevent drift/typos and make it easier to change label conventions later.

[Copilot]

This introduces several magic strings for attribute keys/values (\"builder\", \"type\", \"label\", \"loopback\", \"internal\", \"external\", \"labelled\"). Consider centralizing these as constants (or reusing existing constants/enums if the repo has them) to prevent drift/typos and make it easier to change label conventions later.