Do not divide by zero when a download reports no Content-Length

[Daksha1611]

🛠 Summary

Fixes #4550.

print_progress() computed (float)count / max with max taken straight from libcurl's dltotal. A response using chunked transfer encoding reports dltotal == 0, and the guard in progress_callback only short-circuits while dltotal == dlnow, so once any bytes arrive the callback falls through to print_progress(dlnow, 0, ...).

The ratio is then infinite, and converting that to int is undefined — on x86-64 it yields INT_MIN, so the bar-fill loop does not run and the padding loop below it runs from INT_MIN to bar_width. That is roughly 2.1 billion printf(" ") calls per tick, once a second, so the pull looks frozen and floods the terminal.

Reports the running byte count when the total is unknown, and moves the bar arithmetic into computeProgressBarCells(), which returns 0 for an unknown total and clamps to [0, barWidth]. The clamp also covers a server reporting more bytes than it announced, which previously overran the bar the other way.

computeProgressBarCells() is declared in the header only so the arithmetic can be unit tested — print_progress() is a file-local static that writes to stdout, and there is no existing test surface for the pull module's console output. If you would rather keep the header minimal I am happy to make it static again and drop the tests. The tests live in pull_hf_model_test.cpp, whose target already links curl_downloader transitively, so no BUILD change was needed.

I have no OVMS build container available, so this is not compiled against the full tree and CI will need to confirm the build. I did check the helper in isolation, including reproducing the original INT_MIN result from the two upstream lines. Draft for that reason.

🧪 Checklist

• Unit tests added.
• The documentation updated.
• Change follows security best practices.