fix: reorder histogram samples in multiprocess prometheus output

[saivedant169]

Fixes #5386

What this PR does

BentoML's /metrics endpoint produces histogram metrics in the wrong sample order when running in multiprocess mode. The _sum and _count lines appear before _bucket entries, which violates the Prometheus exposition text format and breaks spec-compliant parsers like fluent-bit's prometheus_scrape.

Before (broken):

# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_sum{...} 0.05
http_request_duration_seconds_count{...} 1
http_request_duration_seconds_bucket{le="0.005",...} 0
http_request_duration_seconds_bucket{le="0.01",...} 0
http_request_duration_seconds_bucket{le="+Inf",...} 1

After (correct):

# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.005",...} 0
http_request_duration_seconds_bucket{le="0.01",...} 0
http_request_duration_seconds_bucket{le="+Inf",...} 1
http_request_duration_seconds_count{...} 1
http_request_duration_seconds_sum{...} 0.05

Root cause

prometheus_client's MultiProcessCollector._accumulate_metrics() processes _sum/_count samples before _bucket entries (buckets go through a separate accumulation pass), and Python's dict insertion order makes them appear first in the output. Single-process mode doesn't have this issue because the underlying metric objects maintain correct sample order.

The fix

After MultiProcessCollector collects metrics, sort histogram samples by:

1. Non-le labels (to preserve label-set grouping)
2. Suffix order: _bucket → _count → _sum
3. le value (ascending) within buckets

This only applies in multiprocess mode since the issue doesn't affect single-process collection.

Coordination

Commented on #5386 here with root cause analysis.

[frostming]

Thank you