Change process.uptime from TimeGauge to FunctionCounter

[mgustimz]

Summary

Changed process.uptime meter from TimeGauge to FunctionCounter in UptimeMetrics. Semantically, process.uptime is a monotonically increasing accumulated value, making FunctionCounter the more appropriate meter type — matching the discussion in PR #7297.

What changed

UptimeMetrics.java

• Changed meter type from TimeGauge to FunctionCounter
• Added .baseUnit("ms") for consistency with the native unit returned by RuntimeMXBean::getUptime

UptimeMetricsTest.java

• Updated test assertions from .timeGauge() to .functionCounter()
• Adjusted expected value from 1.337 (converted to seconds) to 1337.0 (raw milliseconds from mock)

Breaking change note

For registries that treat gauges and counters differently, this is a breaking change for process.uptime. Users monitoring this metric may need to update their dashboards or alerting rules. The issue #7346 notes this was a consideration and it may be appropriate to wait for 2.0 for this change, but the semantic correctness makes it worth proposing now.

Fixes

Fixes #7346

[jonatan-ivanov]

Thank you for the PR!

If this PR was (at least partly) created by some kind of AI tooling, could you please tell us what tool/tools you used so that we can keep the records of it?

I think this should wait for #7329 but also, as the original issue mentioned (#7346) as well as the description of this PR: this is a breaking change and I think we should not do this as-is. At least we should introduce some kind of an opt-in mechanism with probably deprecating the old one: #7311

[mgustimz]

Thank you for the review!

Yeah, this PR was created with assistance from an AI tool (OpenClaw). I'll note that going forward.

Agreed on waiting for #7329 and the opt-in mechanism. The semantic correctness of FunctionCounter for a monotonically increasing value is clear, but you're right that a breaking change deserves a proper deprecation path rather than a silent swap. I'll leave this PR open as a reference and happy to implement the opt-in approach if #7311 moves forward.