ci: add weaver live-check job for host_metrics_receiver

[cijothomas]

Adds a new host-metrics-weaver-live-check CI job that runs the host_metrics_receiver end-to-end against weaver registry live-check (OTLP listener mode) and fails on any violation finding.

Additive only: the existing host-metrics-semconv job is unchanged and the new job is intentionally not in rust-required-status-check.needs for now. Goal is to let both approaches run side-by-side for a while before deciding which to keep and cleaning up.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.92%. Comparing base (f562f90) to head (37cf125).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2986      +/-   ##
==========================================
- Coverage   85.93%   85.92%   -0.01%     
==========================================
  Files         725      725              
  Lines      275782   275782              
==========================================
- Hits       236996   236979      -17     
- Misses      38262    38279      +17     
  Partials      524      524              

Components	Coverage Δ
otap-dataflow	87.05% <ø> (-0.01%)	⬇️
query_abstraction	80.61% <ø> (ø)
query_engine	89.57% <ø> (ø)
otel-arrow-go	52.45% <ø> (ø)
quiver	92.25% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lalitb]

Thanks, the side-by-side approach makes sense. I’d keep host-metrics-semconv as the primary semconv gate because it is deterministic and directly checks the emitted metric shapes against the registry. The live-check adds useful end-to-end runtime/OTLP coverage, but I’d treat it as an integration signal rather than a replacement for the focused semconv check.

[lalitb]

Also -

 [Rust-CI / host-metrics-weaver-live-check (pull_request)](https://github.com/open-telemetry/otel-arrow/actions/runs/25946214606/job/76274753973?pr=2986)
Rust-CI / host-metrics-weaver-live-check (pull_request)Started 36 minutes ago — This check has starte

Is this some timeout issue, as seems to be running for ~ 35 mins

[cijothomas]

Also -

 [Rust-CI / host-metrics-weaver-live-check (pull_request)](https://github.com/open-telemetry/otel-arrow/actions/runs/25946214606/job/76274753973?pr=2986)
Rust-CI / host-metrics-weaver-live-check (pull_request)Started 36 minutes ago — This check has starte

Is this some timeout issue, as seems to be running for ~ 35 mins

#2325 is not yet in! so now resorting to hark kill.

[cijothomas]

 Samples received: **162**
- Entities checked: **3900** (2514 attribute, 1224 data_point, 156 metric, 6 resource)
| Level | Count |
| --- | ---: |
| violation | 0 |
| improvement | 2670 |
| information | 78 |
### Findings by type
| Count | Type |
| ---: | --- |
| 2670 | not_stable |
| 42 | opt_in_attribute_not_present |
| 36 | undefined_enum_variant |
> No semantic-convention violations. Improvements/informations are advisory.

^ output from weaver check! seems working.

[cijothomas]

Okay good to review. This is only to test weaver-live-check in real CI. The main goal is to use this for self-observability proof - tracked via #1613 .

[cijothomas]

@lquerel I think this can be merged now. I have submitted a Draft in Weaver repo to publish a GH Action by Weaver, so it'll be easy for us (and others consuming weaver) to avoid a lot of boilerplates. Once that is done, we can start tackling #1613

[lquerel]

LGTM