fix: tolerate wrapped signed process counters in /proc/stat

[happysnaker]

Summary

• accept wrapped /proc/stat processes counters that appear as signed 32-bit decimal strings
• keep the existing fast path for normal unsigned values
• add regression coverage for the wrapped-counter case

Why

Issue #831 reports systems where /proc/stat exposes processes -2045677862, which currently makes parseStat() fail and breaks all Stat() consumers. The Linux kernel still formats this field from total_forks using %lu, but real systems have been observed to surface the wrapped value as a negative decimal string, including prior node_exporter reports in node_exporter#1882.

This patch keeps the usual ParseUint path for normal hosts, then falls back to parsing a signed 32-bit decimal and reinterpreting it as the original wrapped uint32 value. That preserves the underlying counter instead of failing the whole /proc/stat parse.

[happysnaker]

Follow-up after digging up an older public repro:

• cpu collector/stat collector,couldn't parse -2049562273 (processes) node_exporter#1882 includes a full /proc/stat dump from a real affected host
• that host reported Linux centos 4.14.105-19-0016 x86_64 and exposed:

processes -2045677862

So while we still do not have a complete matrix of affected kernels, there is at least one concrete historical kernel string plus one concrete negative processes sample already in Prometheus issue history.

I think that is enough to justify the parser hardening here: procfs is already seeing this invalid-but-real input in the field, and today we fail the whole /proc/stat parse because of one counter line. This patch keeps the existing unsigned fast path, and only falls back for the observed wrapped negative form.