feat(builder): add metrics to builder client

[markolazic01]

Motivation

Metrics setup.

Description

Additions and notes:

• Basic metrics setup contains wiring + gauges for builder balance and status.
• Chose bc_ as a metric prefix, avoiding collision with lodestar_builder_ in beacon node metrics, and aligned with vc_ on validator.
• Chose port 5065 for metrics server, analog to 5064 in validator.
• No monitoring service until we determine if it's needed.
• Rest api client metrics.

Verified with Kurtosis dev environment setup.

AI Assistance Disclosure

• External Contributors: I have read the contributor guidelines and disclosed my usage of AI below.

Used Claude to check the repo for existing patterns and audit changes. All changes authored manually.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 44d7e415ad

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[nflaig]

LGTM

[markolazic01]

checked the failings, should be fixed with a re-run

[nflaig]

@lodekeeper can you investigate why unit tests are flaky https://github.com/ChainSafe/lodestar/actions/runs/32237943058/job/96025727362?pr=9848, was there a regression we introduced recently? it seems quite common in the last few days for those to run into a timeout

[lodekeeper]

@nflaig I checked the linked job and nearby failures.

The linked unit failure is attempt 2 job 96025727362 on head 0851a1a3; it failed only in packages/state-transition/test/unit/rewards/blockRewards.test.ts > Normal case with the 90s test timeout. The same run's later attempt passed Unit Tests on the same head (96050420029).

The pattern is not #9848-specific: recent unrelated branches hit the same family (packages/state-transition/test/unit/sanityCheck.test.ts phase0/altair perf-state checks and blockRewards.test.ts). Those tests use the 250k-validator perf-state fixture and are already close to the edge even when green: recent successful CI jobs show blockRewards around ~79-110s/file and sanityCheck around ~174-227s/file. I don't see evidence this was introduced by #9848 or by a recent code change in that area.

The remaining red on current #9848 is the separate e2e bucket: runDevCmd.test.ts cleanup hook times out stopping lodestar dev (Hook timed out in 10000ms), with voluntaryExitRemoteSigner also showing setup/teardown timeout fallout. Older green e2e jobs pass runDevCmd around ~10-13s while the hook timeout is 10s, so that also looks like threshold/runner variance rather than the builder metrics diff.

Likely hardening: isolate or raise timeout for the perf-state unit tests (or reduce the fixture/cache cost), and make the child-process e2e cleanup use a bounded kill fallback / longer hook timeout. I haven't found a deterministic recent regression to blame yet.

[wemeetagain]

🎉 This PR is included in v1.47.0 🎉