Avoid division by zero and clock overflow in utilisation rate

[rocker-zhang]

gpuinfo_refresh_utilisation_rate() derives GPU utilisation from
drm-cycles and drm-maxfreq, and is used by the panfrost and panthor
backends. There are two problems in the same computation.

When the fdinfo has no drm-maxfreq key, gpu_clock_speed_max stays 0, so
max_freq_hz is 0 and the utilisation division has a zero denominator.
The double division yields infinity and the subsequent cast to
unsigned int is undefined behaviour. A zero sample delta or a reported
engine_count of 0 hit the same zero denominator. The fix returns early
when the denominator would be zero, which leaves gpu_util_rate unset so
the UI reports N/A rather than a bogus value, matching the existing
if (!gfx_total_process_cycles) return; guard above it.

gpu_clock_speed_max is an unsigned int in MHz; multiplying by 1000000
in unsigned int arithmetic overflows above ~4295 MHz before the result
is stored in the uint64_t max_freq_hz. Casting to uint64_t first keeps
the frequency correct (a 5000 MHz clock gave 705032704 Hz before, and
5000000000 Hz after).

Validation: under UBSan, the zero-frequency case reported
extract_gpuinfo.c: runtime error: division by zero before the guard and
returns cleanly after; a 5000 MHz clock with 2.5e9 cycles over 1 s now
yields 50% (it clamped to 100% before the cast). Built clean on x86_64
(all backends) and arm64, and the gtest suite passes.