MINOR: make Utils.humanReadableByteCount thread-safe via ThreadLocal DecimalFormat

[shoemoney]

Utils.humanReadableByteCount formats through a single static final DecimalFormat shared by every caller. DecimalFormat is documented as
not thread-safe ("Decimal formats are generally not synchronized. It is
recommended to create separate format instances for each thread"), and
format(double) mutates an internal DigitList on each call.

This wraps the formatter in a ThreadLocal so each thread formats
through its own instance; the call site becomes
TWO_DIGIT_FORMAT.get().format(scaled). No behavior change for
single-threaded callers.

Testing: :clients:test --tests UtilsTest passes. I was not able to
produce a corrupted result with a 64-thread stress harness on OpenJDK
21, so this is contract-based hardening rather than a fix for an
observed failure.

[PKNaveen]

Hi @shoemoney do you have way to replicate this bug?

[shoemoney]

Honest answer: no, not deterministically. I wrote a stress harness (12 inputs spanning 1 B to ~7 TB so the shared DigitList sees very different digit counts, 64 threads × 400k calls each, results compared against single-threaded output) and on OpenJDK 21.0.10 it produced zero mismatches. The PR body's "corrupts output" was overstated — the basis for the change is the DecimalFormat Javadoc ("not synchronized … create separate format instances for each thread"), not an observed failure in Kafka. I've rewritten the description to say exactly that. If a ThreadLocal for a contract-only race isn't worth carrying, I'm fine closing this; if you'd rather keep the hardening, it's rebased and green.

[github-actions]

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.