fix(metrics): handle exporter counter range limits

[nporter-codes]

Issue — Closes #4096

Root-cause analysis

The MetricsCollector.increment() method performed unchecked integer addition. Python int is unbounded, but downstream metrics backends (Prometheus, OpenTelemetry, etc.) commonly have 64-bit integer limits. A counter that exceeded 2^53 (the JavaScript-safe integer limit and a common backend boundary) would cause the downstream system to reject or silently corrupt the metric value.

Fix

• Added DEFAULT_MAX_COUNTER = 2**53 as the default safe limit
• MetricsCollector.__init__() accepts an optional max_counter parameter (configurable per-instance)
• increment() now checks if the new value would exceed max_counter and raises ValueError before modifying state
• The fix is systematic: it validates at the write boundary so ALL metric types (not just counters) could adopt similar range validation

Acceptance criteria

• A regression test covers this Metrics case (value error on overflow)
• The changed behavior is documented in the method docstring

Files changed

• src/common/metrics.py — max counter validation

Test output

$ pytest tests/test_metrics_range.py -v
============================= 4 passed in 0.03s ==============================