Bar-left, no frame, █/░ fill, ETA, estimated download size from
unpackedSize, fast-mode bypass for sub-2s installs, and `linking`
phase word in place of dropped `[N/3]` counter. CI mode and TTY mode
share the same label assembly.

Also fixes two real bookkeeping bugs surfaced while reworking the UI:

* "2/1 packages" overflow: fresh-resolve streamed `inc_total` only
  for non-deferred packages, but the post-`filter_graph` catch-up
  fetch credited deferred-but-survived packages to the numerator
  without a matching denominator bump.
* "Stuck at 90%" undercount: streamed `inc_total` for every resolved
  package including platform-mismatched optionals that
  `filter_graph` then dropped, inflating the denominator past the
  surviving graph size.

Both fixed by moving `inc_total(1)` ahead of the deferred-skip and
reconciling with `set_total(graph.packages.len())` after
`filter_graph`. Display clamp + new `WARN_AUBE_PROGRESS_OVERFLOW`
remain as defensive guards.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Skip empty bytes_segment so the phase-2 label doesn't render a
  doubled `·  ·` separator on installs without `dist.unpackedSize`
  (Greptile P1).
* Switch ETA to fetch-window throughput: snapshot completed at the
  set_phase("fetching") boundary, then divide remaining work by
  `fetch_elapsed_ms / (completed - baseline)`. Falls back to `ETA …`
  while the baseline or fetch window are missing. Eliminates the
  pessimistic "110s ETA after a 3s resolve" case (Greptile P2).
* Reconcile estimated_bytes after filter_graph: track per-dep_path
  unpacked_size during streaming, then re-sum surviving dep_paths
  via the new InstallProgress::reconcile_estimated_bytes API.
  Mirrors the package-denominator reconcile applied next to it
  (Greptile P3).
* Apply TARBALL_COMPRESSION_RATIO in TTY refresh_bytes_segment too —
  CI mode applied it; TTY was showing the raw unpacked sum (~3.3×
  inflated) (Cursor #1).
* Refresh ETA on every inc_downloaded_bytes so it doesn't freeze
  during long downloads when no inc_total / inc_reused events fire.
  Documents the trade-off at FetchRow::drop where a refresh would
  require a larger refactor (Cursor #3).
* Style only the ✓ green on the install / no-op summaries instead
  of the whole sentence; aligns with the CI heartbeat summary's
  styling so the success cue stays sharp without bleeding green
  across the line (Cursor #4 + user request).
* Standardize the ✓ prefix on both Already-up-to-date paths
  (`print_install_summary` and `print_already_up_to_date`).

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* `inc_estimated_bytes` now subtracts any prior recorded value
  before adding the new one, so a duplicate dep_path stream
  (defensive case the resolver shouldn't produce but isn't
  prevented from producing) keeps the atomic running total in
  lockstep with the HashMap. Without this the running estimate
  overcounts until `reconcile_estimated_bytes` re-syncs at the
  filter_graph boundary, and the bar shows an inflated `~X MB`
  in the meantime.
* `print_already_up_to_date` now goes through the shared
  `aube_prefix_line` helper instead of reconstructing the
  `aube VERSION by en.dev · <msg>` shape inline. Eliminates the
  drift risk between this site and `print_install_summary`'s
  no-op branch — both render identically by construction.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Hoist the `clamped_completed` call out of `bar_only` and
  `label_for` and into a single computation at the top of
  `progress_line`, threading the result through as a parameter.
  Previously the clamp ran twice per render tick — once for the
  bar, once for the label — and so did the diagnostic warning.
* Gate `tracing::warn!(WARN_AUBE_PROGRESS_OVERFLOW)` behind a
  process-wide `AtomicBool::swap` latch so the warning fires at
  most once per CLI run. The bookkeeping condition tends to recur
  across heartbeats once tripped; without this gate the CLI would
  log dozens of identical warnings to stderr, drowning out the
  actual install output. One warning per session is enough to
  flag the regression for follow-up.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>