fix(#562): align merge_success counter denominator with segment-level numerator

[HenryLach]

Closes #562.

The bug

In a polyrepo batch where task-level waves expand into segment-level merge rounds (3 task waves → 6 segment rounds in the reporter's case), the operator-visible merge alerts overflowed their denominator:

✅ Wave 1 merged successfully (1/3). Tests pass.
✅ Wave 2 merged successfully (2/3). Tests pass.
✅ Wave 3 merged successfully (3/3). Tests pass.
✅ Wave 4 merged successfully (4/3). Tests pass.   ← stale denominator
✅ Wave 5 merged successfully (5/3). Tests pass.
✅ Wave 6 merged successfully (6/3). Tests pass.

Purely cosmetic — every wave merged successfully. Functionality unchanged.

Root cause

The supervisor's formatEventNotification renders Wave N merged successfully (X/Y) where:

• N and X both derive from event.waveIndex + 1 (set by the engine to the segment-round index 0..5)
• Y came from event.totalWaves which the engine was populating with taskLevelWaveCount (the pre-expansion task-wave count = 3)

Once segments expanded, N/X overflowed Y. The fix is to source the denominator from batchState.totalWaves (assigned rawWaves.length at engine.ts:2767 — the segment-expanded round count) instead.

The fix

One-field source-of-truth swap at the merge_success event emission site in engine.ts:

- totalWaves: taskLevelWaveCount,
+ totalWaves: batchState.totalWaves,

Plus an inline comment explaining the segment/task-wave distinction so a future reader doesn't reintroduce the bug.

Test

Adds 5.8a to supervisor.test.ts: emits 6 successive merge_success events with waveIndex 0..5 against totalWaves: 6 and asserts:

1. Each rendered counter reads (waveIdx+1)/6.
2. None of the rendered counters contain the buggy /3 pattern from the report.

Validation

Gate	Result
npm run typecheck	✅ pass
npm run lint	✅ 286 warnings / 671 infos — identical to main (zero new)
npm run format:check	✅ pass
supervisor.test.ts (114 tests)	✅ all pass, new 5.8a included

Note on the design choice

The reporter offered two options: (a) flip the denominator to segment-level (what this PR does), or (b) reword the alert to disambiguate units. I went with (a) because:

1. The numerator was already segment-level — this just aligns the denominator. Minimal surface area, no message rewording.
2. The supervisor's existing leading Wave N is also segment-level (uses waveIndex + 1), so changing the denominator gives the whole message a consistent unit system without touching any other emission sites.
3. The reporter explicitly endorsed this as the preferred fix in the issue body ("one-character source-of-truth swap").