Keep the progress bar moving for the whole run

Three stretches of a run had no way to report anything, and the bar
handled each of them badly.

pacman prints nothing at all between "starting full system upgrade" and
the transaction it eventually prepares. On a 161-package backlog that
silence ran to three minutes and nineteen seconds, and the bar spent all
of it frozen on "0 of 161" - a counter seeded from checkupdates before
there was anything to count. Working out the upgrade is now a step of its
own, with a label and deliberately no item count, because the number was
the part that was lying.

A step that turns out to have no work is dropped from the bar instead of
being handed its share for nothing. Packages already in the cache are
never announced by pacman, so a run that only has to unpack used to jump
thirty points the moment unpacking started; the same went for AUR with
nothing pending and for machines with no Gear Lever or no Flatpaks.

pacman's output is line-buffered through stdbuf. Writing to a log rather
than a terminal, libc released it in 4KB blocks - around a hundred and
sixty "upgrading foo..." lines at a time - so the bar sat still and then
leapt to the end of the step in one poll.

What is left is work whose length genuinely cannot be known: resolving a
transaction, and an AUR helper compiling for a quarter of an hour. Those
now creep along a curve that approaches the end of their step without
reaching it. The item counter stays put throughout - it is the field that
would be lying if it moved - and any real report overtakes the creep. A
bar that has not moved since it appeared is read as a hang, and somebody
who reads it that way reaches for the power button mid-update.

The bar is also monotonic now. Dropping a step rescales the run, and the
conflict-recovery loop restarts pacman and its tally from the top; both
are honest, neither is a reason to show a bar that retreats.

doc/cachy-auto-update.1.scd

@@ -122,18 +122,29 @@ of the update and holds that connection open. It requires _python-gobject_.
 Where that is missing, or on a desktop with no job interface, there is no
 progress entry and nothing else is affected.
 
-Fetching the packages and unpacking them are two steps rather than one. On a
-domestic line the download is the longer of the two, and a bar that called the
-whole thing "installing" would sit near its beginning for minutes at a time
-looking stuck.
+Working out the upgrade, fetching it and unpacking it are three steps rather
+than one. Between "Starting full system upgrade" and the transaction it
+eventually prepares, pacman prints nothing at all, and on a large backlog that
+silence runs to minutes; that stretch therefore carries a label of its own and
+deliberately no item count, because a counter frozen at "0 of 161" reads as a
+stuck update. On a domestic line the download is then the longest of the three,
+and a bar that called the whole thing "installing" would sit near its beginning
+for minutes at a time looking stuck.
 
-Neither phase gets a counter from pacman on an unattended run, so both are
-counted here, a line at a time: "foo-1.2-1-x86_64 downloading..." for the
-first, "upgrading foo..." for the second. Packages already in the cache are
-never announced, so the download step regularly ends short of its total and
-gives up the rest of its share when unpacking begins. pacman's other (n/m)
-sequences - checking keys, package integrity, loading package files - each
-count up to the same total and are deliberately ignored.
+A step that turns out to have no work is dropped from the bar instead of being
+handed its share for nothing. Packages already in the cache are never
+announced, so a run with everything already fetched skips the download step
+outright rather than jumping when unpacking starts; the same applies to AUR
+with nothing pending, or a machine with no Flatpaks installed.
+
+Neither counted phase gets a counter from pacman on an unattended run, so both
+are counted here, a line at a time: "foo-1.2-1-x86_64 downloading..." for the
+first, "upgrading foo..." for the second. pacman's output is line-buffered
+through *stdbuf*(1) so those lines arrive as they happen - writing to a log
+rather than a terminal, libc would otherwise release them in 4KB blocks, around
+a hundred and sixty packages at a time. pacman's other (n/m) sequences -
+checking keys, package integrity, loading package files - each count up to the
+same total and are deliberately ignored.
 
 # HOW LONG NOTIFICATIONS STAY