feat: estimate the time remaining from bytes and observed rate

rsync reports each file's size with %l as it completes, which is all an
estimate needs: bytes done over time elapsed is the same arithmetic rsync would
do internally, and requires nothing it does not already print. The scan pass now
sums those sizes as well as counting files, so both a percentage and an estimate
have a real denominator.

The rate is measured over a trailing thirty seconds rather than the whole run,
so it follows a device that slows down instead of averaging the slowdown away --
which for a card reader that thermally throttles, or a USB link that renegotiates
after an hour, is the difference between a useful estimate and a reassuring one.

Below two seconds no rate is reported at all. The first handful of files arrive
microseconds apart, and dividing by that window produces a rate in the gigabytes
per second and an estimate of zero, which is worse than showing nothing.

Directory entries are excluded from the byte total as well as the file count.
rsync reports them with a 4096 inode size, which across six thousand album
directories is several megabytes of transfer that never happens.

README.md

@@ -166,15 +166,24 @@ remove the Rockbox install.
 Progress is a single line that rewrites itself:
 
 ```
-[ 12,345 / 49,600  24%] King Gizzard & the Lizard Wizard / PetroDragonic Apoc…
+[ 24%] 12,345/49,600  3.2 GiB/13.1 GiB  4.4 MiB/s  ETA 38m12s  King Gizzard / Petro…
 ```
 
+The estimate comes from rsync's `%l`, which gives each file's size as it
+completes. Bytes done over time elapsed is the same arithmetic rsync would do,
+and needs nothing it does not already print. The rate is measured over a
+trailing thirty seconds rather than the whole run, so it follows a device that
+slows down instead of averaging the slowdown away — and it is suppressed
+entirely for the first two seconds, where the window is microseconds wide and
+would report gigabytes per second.
+
 rsync says nothing at all while it builds its file list, which on fifty
 thousand files over USB is minutes of apparent hang, and its own `progress2`
 percentage is computed against a list it has not finished discovering. So the
-script counts first — a second pass over the tree, which is what a percentage
-that means something costs — and renders the rest itself. Piped to a log it
-prints a plain line every thirty seconds instead, with no carriage returns.
+script counts first — files and bytes both, a second pass over the tree, which
+is what a percentage and an estimate that mean something cost — and renders the
+rest itself. Piped to a log it prints a plain line every thirty seconds
+instead, with no carriage returns, and a summary at the end either way.
 
 The unmount is the point of doing this in a script. FAT32 has no journal and
 the device is reached through disk mode, so an interrupted write is corruption