Show the run log's last lines under Details, live

The percentage says an update is alive. It does not say what it is alive
doing, and for the longest stretch of a run there was no way to find out:
an AUR package compiling for a quarter of an hour talks constantly, and
every word of it went into a file nobody was looking at.

So the run log's last five lines now travel with the progress entry and
sit under Details, refreshed every two seconds for as long as the update
lasts. Polled rather than followed, for the same reason the pacman
watcher polls: only the last few lines are ever displayed, so every line
in between would be work nobody sees, and re-reading the tail whole makes
truncation and rotation of the log a non-event.

The job model behind this interface carries exactly two description
fields - descriptionValue1 and 2, there is no third - so one stays with
the package being worked on and the other takes the tail. Newlines inside
a field do render, which is what lets five lines share one of them. They
travel tab separated because the protocol is one instruction per line,
and a tab inside a log line becomes a space first: either renders as
whitespace, but a line split in half renders as nonsense. Five lines
clipped to 120 columns also keeps an instruction well inside PIPE_BUF,
which is what makes the write atomic against the runner sending its own
progress down the same pipe.

README.md

@@ -228,6 +228,14 @@ Two things about how it is put together:
   instead of leaping 30% the moment unpacking starts — and likewise for AUR
   with nothing pending, or a machine with no Flatpaks. The weights only ever
   have to be right about the steps that actually run.
+- **Expanding *Details* shows the run log's last five lines, live.** The
+  percentage says the update is alive; these say what it is alive doing. It
+  matters most where there is nothing to count — an AUR package compiling for
+  a quarter of an hour talks constantly, and all of it used to go into a file
+  nobody was looking at. The job model behind this interface carries exactly
+  two description fields (`descriptionValue1` and `2` — there is no third), so
+  one holds the current package and the other the tail; newlines inside a value
+  do render, which is what makes five lines fit in one field.
 - pacman's output is line-buffered through `stdbuf`. Writing to a log rather
   than a terminal, libc would hand it over in 4 KB blocks instead, and 4 KB of
   `upgrading foo...` is on the order of a hundred and sixty packages arriving