Better progress indicators for optimize (counter + collapse per-site lists)

[MarcinDudekDev]

Summary

ROADMAP.md v0.10.x UX item: Better progress indicators.

--no-color is done. Dry-run wording is PR #5 (open — do not rework past-tense vs would-apply). JSON is PR #7 (open — do not touch). This item is independent: make long optimize runs show where they are, and stop dumping one line per site.

Today, on main:

• apply_optimizations prints ui_step "Applying $display_name..." — a completed checkmark — before the feature runs. In-progress looks finished.
• There is no i/n counter. A 15-feature run with 33 sites looks stuck.
• HTTP/3 and Redis print one Would configure HTTP/3 -> <site> (or Redis equivalent) line per site. 30+ lines of identical noise. PR fix: clean up dry-run output in interactive mode #5 explicitly deferred collapsing those lists to this item.

ui_step_pending already exists in nginx-optimizer-lib/ui.sh. Use it.

Acceptance criteria (testable)

Branch from origin/main. Do not base on feat/dry-run-output-cleanup or feat/json-output.

A. Feature-loop progress

In nginx-optimizer-lib/optimizer.sh apply_optimizations:

1. While a feature is running, the in-progress line uses ui_step_pending (○), not ui_step (✓/*). After success, ui_step for the result line is fine.
2. Every feature in-progress line includes a counter i/n (or [i/n]) where n is the number of features this run will attempt (after --feature / --exclude filters) and i is 1-based.
3. --quiet still suppresses the UI (existing behaviour). --json is unaffected (optimize has no JSON path).

Verify with:

./nginx-optimizer.sh optimize --dry-run --no-color --force

Stdout must match (regex, ANSI-stripped):

• A pending/in-progress marker line containing both 1/ (or [1/) and a feature name before that feature's "Would deploy" / result lines. On current main the in-progress line is a completed checkmark and has no counter — that is the fail-on-main test.
• A counter whose denominator equals the number of feature result lines in that run (not hard-coded 15).

Do not require rewriting "applied" vs "Would apply" — that is PR #5. On main, result lines still say applied. Leave them.

B. Collapse per-site lists

4. When HTTP/3 (and Redis, same pattern) would print more than 5 per-site ui_step_path lines in one apply, print one summary line with the count instead, e.g. Would configure HTTP/3 -> 33 sites / Configured HTTP/3 -> 33 sites. 5 or fewer sites: keep per-site lines.
5. --verbose keeps the full per-site list (all sites). Default / --force dry-run uses the collapse.

Fail-on-main test: optimize --dry-run --no-color --force --feature http3 stdout, on a machine with >5 sites, must not contain 6+ distinct Would configure HTTP/3 lines. After the fix it contains one count line (or ≤5 site lines).

Same idea for Redis Would add Redis to.

C. Tests + lint

6. New assertions in tests/run-tests.sh for A (counter present; in-progress is not only completed-check style for the "Applying"/"Previewing" line if that's what main prints) and B (http3 dry-run does not emit >5 Would configure HTTP/3 lines when site count >5; skip with a reason if the machine has ≤5 sites).
7. Those assertions fail on current main.
8. ./tests/run-tests.sh green.
9. shellcheck --severity=warning nginx-optimizer.sh nginx-optimizer-lib/*.sh lib/registry.sh lib/core/*.sh lib/features/*.sh
10. Bash 3.2 only.
11. Check off ROADMAP.md Better progress indicators.

Out of scope

• Dry-run past-tense cleanup (PR fix: clean up dry-run output in interactive mode #5).
• JSON (PR fix: full JSON output for analyze/status/list/check #7).
• doctor, diff, spinner animations, percentage bars, rewriting live apply copy beyond pending+counter.
• Changing what features do.