refactor(web): clearer bake-progress card + visible prepare stage

[beetlebugorg]

Reworks the tile-bake progress UI in the bottom status card for legibility and calm, and makes the previously-invisible per-band parse/portray pause a first-class reported stage.

UI (web):

• Three stacked pieces: region TITLE on top (stable headline), the live ACTION beneath it (left) with the COUNT pinned right. No percentage — the bar alone carries the proportion, so the count is the only moving number.
• Removed the always-on spinner; the indeterminate state is a single slow sweep (reduced-motion collapses it to a static bar).
• Every count spells out its unit in every stage ("7 / 12 charts", "1,234 / 4,567 tiles", "12 MB / 45 MB"); the action carries the band but not the noun, so the unit is never doubled. "charts" matches the app's established user-facing voice (internal "cells" stays in code/API).
• NotificationCenter task contract gains a detail (count) field; progress(frac, sub, detail). chart-library task labels are now the region title; per-cell/rebake paths split action/count.

Baker/server — report the prepare stage:

• The long gap between bands is addCellsParallel (re-parse + S-101 portrayal) plus the pass-1 coverage scan; progress was only emitted while emitting tiles, so the bar froze. addCellsParallel now takes a per-cell onCell hook, and BakeToPMTilesBandsStreaming's progress callback carries a stage ("prepare" per cell, "tiles" per tile) and the band slug.
• import.go maps stage -> unit (cells/tiles) + band onto the job status JSON; CLI bake prints band + stage. Bake output is byte-identical (progress is observational only; baker determinism tests green).