Fix multiple idle latency steps overriding previous measurements

[carlosefr]

When multiple { type: 'latency' } steps exist in the measurements config (e.g. the interleaved 2-ping idle probes added between bandwidth phases), each step was overwriting the previous step's timings in raw.latency.results. Only the last latency phase's data survived.

This fix snapshots the existing timings before each latency phase starts and prepends them on each measurement callback, so all phases accumulate into a single timings array.

Also logs the results payload to the console before submission to __results.

[ask-bonk]

Review summary

What this PR does

• Fixes a real bug where multiple { type: 'latency' } steps in the measurements config clobber each other. Because #curTypeResults() keys raw by measurement type (src/index.ts:263-269), every latency step reads/writes the same raw.latency object. Each phase's callback did msmResults.results = Object.assign({}, res.down[0]), replacing the whole object and dropping the prior phase's timings. The fix snapshots priorTimings when the phase starts and prepends them on each callback, so all phases accumulate into one timings array. Diagnosis and approach are correct.
• Adds a console.log('results', logData) in logFinalResults.ts before the __results POST.

Correctness verification

• No double-counting: the engine rebuilds res.down[0].timings cumulatively within a phase (BandwidthEngine.ts:296-299), and priorTimings is a fixed snapshot of previous phases, prepended fresh each callback. Correct.
• Pause/resume is safe: latency is pausable, but resume returns early in #next() without re-entering the switch (src/index.ts:304-315), so priorTimings is captured exactly once per phase. Correct.

Overall the core fix is sound. A couple of minor issues flagged inline.

[ask-bonk]

Review posted to PR #132.

Summary

What the PR changes

1. src/index.ts — Fixes a real bug. Since #curTypeResults() keys raw by measurement type, all { type: 'latency' } steps share the same raw.latency object. Each phase's callback did msmResults.results = Object.assign({}, res.down[0]), wiping out the previous phase's timings so only the last phase survived. The fix snapshots existing timings at phase start and prepends them on each callback, accumulating all phases into one array.

2. src/logging/logFinalResults.ts — Adds a console.log('results', logData) before the __results POST.

Verdict on the fix: The core fix is correct. I verified no double-counting (the engine rebuilds its timings cumulatively within a phase, and priorTimings is a fixed snapshot of only prior phases) and that pause/resume is safe (resume returns early without re-entering the switch, so the snapshot is captured once per phase).

Issues flagged inline

• logFinalResults.ts:131 (style/production concern) — The console.log is unconditional and ships to production, printing the full payload to every visitor's console. PR body says it's for debugging; recommend removing or gating behind a debug flag.
• index.ts:531 (minor defensiveness) — priorTimings.concat(res.down[0].timings) would append a literal undefined if timings were ever undefined. Not reachable today (engine always inits timings: []), but a || [] guard would match the guard already used on line 520.

No correctness or security blockers. No commits pushed.

github run