One notification per thing running, grouped, and an em dash between the two names

Two builds at once were two lines inside one notification; they are now
two notifications in one group, each with its own title and its own bar,
which is what the shade is for -- and what lets a component that
finishes take its own row down while its sibling carries on. Rows are
keyed by a tag (<key>/<component>) rather than an id, so an update
replaces the row it is about and two components cannot collide, and
`drawn` is the path out for one whose work is over.

A foreground service needs one notification that outlives every row, so
the service's own is the row itself while one thing is running and the
group's summary once there are more. Measured on API 36: a group of one
is collapsed to its header, which is the line of text with the bar left
out of it -- so grouping a single row would cost it the progress it had.
Verified on the emulator through all four states: one row with its
count, two grouped rows with a bar each, the fast one finishing and
leaving the other as a single row again, and everything gone when the
last build lands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -125,8 +125,8 @@ phone. Paths accept `~`, and are shown that way.
 
 While anything is building, downloading or installing, the app keeps an
 ongoing notification saying what is running and how far along it is — one
-line per component, with each build's own count where the command reports
-one. It is there to be watched, and it is also what keeps the work alive:
+per thing, grouped together, each with its own build's count where the
+command reports one. It is there to be watched, and it is also what keeps the work alive:
 without it the app is an ordinary backgrounded process, and Android is
 free to reclaim it partway through a build. It goes away by itself when
 the last thing finishes. Refusing the notification permission costs the