[eeeebbbbrrrr]

Summary

• render the three human-readable byte totals in list progress as gigabytes with three decimal places
• leave raw byte accounting and JSON output unchanged
• keep this PR independent from the SQLite query fix

Validation

• Ubuntu 24.04 container build: passed
• pgcopydb list progress against a copied catalog fixture: passed; values rendered as 2442.193 GB, 120.521 GB, and 788.694 GB
• PGVERSION=16 make tests/unit: blocked before tests start because the repository Debian 11 image receives 404 responses for current bullseye-security package URLs

[teknogeek0]

The precision problem is real, but the fix here lands in the wrong place. Three things:

1. progress.c:1002-1004 still calls pretty_print_bytes for the JSON total-pretty, done-pretty and in-progress-pretty fields. After this change list progress prints 2442.193 GB and list progress --json prints 2442 GB for the same number.
2. A fixed GB unit renders a small migration as 0.000 GB in all three columns, where the current code shows 500 MB.
3. The column is %12s, and 12345.678 GB is exactly 12 characters wide.

The root cause is the (int) cast in pretty_print_bytes (string_utils.c:644). Suggest adding a pretty_print_bytes_precise beside it that keeps the unit scaling and takes three decimals, then calling it from both cli_list.c and progress.c. That gives precision at every magnitude and keeps the two outputs in agreement. Best to leave pretty_print_bytes alone — the comment above it says some callers need the integer form.