refine poll_until_metric_gte to support label-specific assertions

[gimballock]

Context

poll_until_metric_gte in integration-tests/lib/prometheus_metrics_assertions.rs currently matches any label combination for a metric name. For example, polling sv2_client_shares_accepted_total returns true if any channel has shares, regardless of which channel_id or user_identity.

Goal

Add a variant (or extend the existing function with an optional label selector) so tests can make precise assertions like:

sv2_client_shares_accepted_total{channel_id="1",user_identity="user1"} >= 1

This would make polling assertions as precise as the static assert_metric_eq helper, which already supports full label selectors via parse_metric_value.

Suggested approach

Add poll_until_labeled_metric_gte(addr, metric_with_labels, min, timeout) that delegates to the existing parse_metric_value for label-aware matching, rather than the current line-scan approach.

Raised in PR #281 by @GitGab19.

[gimballock]

Context update after PR #338

PR #338 (addressing #337) proposes moving GaugeVec metric updates from the per-request /metrics handler into the background SnapshotCache::refresh() cycle, replacing the blanket .reset() with a PreviousLabelSets diff that only .remove()s stale label combinations.

This changes the picture for this issue:

The original problem is going away. The reason poll_until_metric_gte was introduced alongside the monitoring integration tests was to tolerate the .reset() gap — where every /metrics scrape momentarily zeroed all GaugeVec label series. That race window is eliminated by #338. Without the gap, a single scrape after a cache refresh will always return correct, non-zero values.

Polling still exists but for a different reason. Post-#338, poll_until_metric_gte waits for the background cache refresh interval (not a per-request race). This is inherent to the cache architecture and not something label-specific matching would solve. The existing sniffer.wait_for_message_type() confirms shares have been accepted, but the monitoring cache may not have refreshed yet.

The label-specificity enhancement becomes a nice-to-have, not a correctness fix. Tests can already use parse_metric_value with a full label selector (e.g. sv2_client_shares_accepted_total{channel_id="1",client_id="1",user_identity="user1"}) for static assertions after polling confirms the metric is populated. Wrapping that into the polling loop would be a convenience improvement but no longer addresses a reliability issue.

I'd suggest either downgrading this to low-priority or closing it in favor of a smaller follow-up, pending #338 landing.