Drive the install bar from packages, not from a stopwatch

install_progress() mapped each phase to a start%, an end% and a hard-coded
"expected seconds", then interpolated on elapsed time. Those seconds were
calibrated on one machine, so the bar was only ever honest on that machine.
Measured against a real 69s install on an XPS 13, the table expected 145s: 95s
for a phase that took 58.6s, 10s for one that took 2.6s. On slow media it is
wrong the other way — the bar reaches each phase's ceiling in a fraction of the
real time and then sits there. Today's clamp turns that into a 386-second freeze
at 85% on a USB2 install.

Phases do not even scale together: package installation is bound by media read
and disk write, the UKI rebuild is CPU and compression bound. No single seconds
table can be right for both.

So stop predicting durations. Position is now max(floor, work), both
non-decreasing:

  floor  an asymptote over the phase's band, on time since this process first
         saw the phase. tau is a shape constant, not a prediction — wrong by 3x
         it changes the pace of a crawl, never the correctness.
  work   only for "Installing Arch + Omarchy", which is ~85% of the install.
         libalpm creates one directory per package under
         <target>/var/lib/pacman/local, so counting them counts finished work.
         The denominator is resolved at ISO build time by pacman's own resolver
         against the offline mirror, so there is no second package list to
         drift. phases.py records expected and actual in the timing JSON on
         every install, so drift shows up in acceptance runs.

There is deliberately no give-up predicate: two discontinuous curves selected by
a toggle, behind a monotonic clamp, is a freeze generator. If the signal never
appears — no denominator, wrong target, implausible count — the floor alone
still walks the band to its end.

Position moves to per-mille. That is load-bearing, not precision theatre: these
are asymptotes, and in whole percent an asymptote over a 2-point band has two
reachable values and stops moving within seconds.

Time now comes from /proc/uptime. The live ISO runs tzupdate and
systemd-timesyncd, and the old code read EPOCHSECONDS, so a clock step
mid-install jumped every band straight to its ceiling.

Also fixes drift the old table had accumulated: it still weighted five phases
that no longer exist and had no entry at all for "Preparing install target",
which fell through to a 1->99 sweep. Unknown names now derive an even band from
the index the orchestrator already publishes.

bin/omarchy-iso-installer fakes a pacman database so the preview exercises the
package path instead of the fallback; PREVIEW_PACKAGES tunes the count.

Verified by simulation against the real logic: a 69s NVMe install, a 6-minute
USB2 install with a 70s pre-extraction stall, an implausible denominator, an
unknown phase name, and a target that already holds packages. All monotonic, all
reach 100%. Not yet run on real hardware.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

builder/build-iso.sh

@@ -234,6 +234,70 @@ repo-add "$offline_mirror_dir/offline.db.tar.gz" "$offline_mirror_dir/"*.pkg.tar
 mkdir -p /var/cache/omarchy/mirror
 ln -sf "$offline_mirror_dir" /var/cache/omarchy/mirror/offline
 
+# Denominator for the install dashboard's progress bar. Resolving the mirror's
+# own package lists against the mirror we just indexed, with an empty local db,
+# is the question pacstrap asks at install time — same resolver, same repo, same
+# lists — so no hand-kept constant can drift.
+#
+# It over-counts by ~1 in 925: archinstall.packages lists both amd-ucode and
+# intel-ucode because the mirror must contain either. phases.py records expected
+# and actual in the timing JSON, so growing drift shows up in acceptance runs.
+# The early-bootstrap set is already inside this closure, so restating it would
+# only add a second list to drift.
+resolve_expected_packages() {
+  local resolve_root=/tmp/omarchy-expected-packages
+  local resolved
+  local -a targets
+
+  rm -rf "$resolve_root"
+  mkdir -p "$resolve_root/var/lib/pacman"
+
+  mapfile -t targets < <(
+    {
+      grep -hv '^#\|^$' /builder/archinstall.packages
+      # Read the shipped copy, which is what _runtime_package_list reads at
+      # install time, not the build-time source it came from.
+      grep -hv '^#\|^$' \
+        "$build_cache_dir/airootfs/usr/share/omarchy-iso/omarchy-base.packages"
+      printf '%s\n' "$OMARCHY_RUNTIME_PACKAGE" "$OMARCHY_SETTINGS_PACKAGE" \
+        "$OMARCHY_NVIM_PACKAGE"
+    } | sort -u
+  )
+
+  pacman --config "$build_cache_dir/pacman-offline.conf" \
+    --root "$resolve_root" --dbpath "$resolve_root/var/lib/pacman" \
+    --noconfirm -Sy >/dev/null || return 1
+
+  # Capture before counting: no pipefail here, so a pacman failure inside a
+  # pipeline would become a plausible partial count, which never trips the
+  # dashboard's fallback.
+  resolved="$(pacman --config "$build_cache_dir/pacman-offline.conf" \
+    --root "$resolve_root" --dbpath "$resolve_root/var/lib/pacman" \
+    --noconfirm -S --print --print-format '%n' "${targets[@]}")" || return 1
+
+  printf '%s\n' "$resolved" | sort -u | grep -c .
+}
+
+# Worth failing the build over: -S --print only aborts when a target is missing
+# from the offline repo, which would fail pacstrap the same way. A count that
+# merely looks wrong is not — the dashboard falls back without the file.
+if ! expected_packages="$(resolve_expected_packages)"; then
+  echo "ERROR: could not resolve the target package count from the offline mirror." >&2
+  echo "       pacman -S --print aborts the whole transaction if any single target" >&2
+  echo "       is missing, so this almost certainly means pacstrap would fail the" >&2
+  echo "       same way at install time." >&2
+  exit 1
+fi
+if (( expected_packages < 600 || expected_packages > 2000 )); then
+  echo "WARNING: resolved target package count $expected_packages is outside the" >&2
+  echo "         expected 600-2000 range; shipping no denominator so the install" >&2
+  echo "         dashboard falls back to its time-based curve." >&2
+else
+  printf '%s\n' "$expected_packages" \
+    >"$build_cache_dir/airootfs/usr/share/omarchy-iso/expected-packages"
+  echo "Target install resolves to $expected_packages packages."
+fi
+
 # Live ISO uses the same offline pacman.conf.
 cp "$build_cache_dir/pacman-offline.conf" "$build_cache_dir/airootfs/etc/pacman.conf"