feat: return 0.0 early for HTTP 401/403/404/429 in _process_response (response_status label change)

[coderabbitai]

Summary

In common/metric_types.py, HttpCallLatencyMetricBase._process_response currently raises aiohttp.ClientResponseError for all non-200 HTTP statuses, including 401, 403, 404, and 429. The existing BaseMetric.handle_error() then gates on MetricsServiceConfig.IGNORED_HTTP_ERRORS and returns early, so no metric value is pushed to Grafana — matching the silent-ignore spec.

An alternative would be to return 0.0 early (and clear _captured_block_number) for those statuses directly inside _process_response. However, this would flip the emitted response_status tag from failed to success for 401/403/404/429 responses, which is a dashboard-observable behavior change.

Scope of impact

• Affects all HttpCallLatencyMetricBase subclasses across every chain.
• Any Grafana dashboard panel that filters or aggregates on response_status=failed vs response_status=success would see different results.
• Requires an explicit dashboard review before merging.

Action items

• Implement early return 0.0 path for {401, 403, 404, 429} in _process_response
• Clear _captured_block_number on the early return path
• Audit all Grafana dashboards for panels using response_status label
• Update dashboard queries / alerts as needed
• Add or update tests covering the new early-return path

References

• PR feat: emit raw block numbers for lag tracking across all chains #59 (block-number capture work): feat: emit raw block numbers for lag tracking across all chains #59
• Discussion comment: feat: emit raw block numbers for lag tracking across all chains #59 (comment)

Requested by @smypmsa.