fix(cli): await trailing progress-log writes before settling download

[EhabY]

Fixes #1120

Root cause

CliManager.download() settled its promise on a progressWrite captured by value at the moment the read stream closed. A chunk write still in flight at that point was never awaited, so clearProgress() could delete binary.progress.log first and the trailing write would recreate it, leaving the file behind permanently. That is why the concurrent test failed only on the progress-log line and no vi.waitFor timeout could fix it.

Fix

Two changes in download():

• Progress-log writes are chained onto the previous one, so awaiting the final progressWrite awaits every write, not just the last.
• All three settle paths (success, read error, write error) settle only after the write stream emits close, which fs guarantees fires after every pending write callback.

Cleanup can no longer race a trailing write, on any scheduler.

Tests

• New regression test holds fs write callbacks until close(), like a real stream on a loaded runner. Fails on unfixed code, passes with the fix.
• withStreamError("write") now emits close after error, matching real fs with autoClose: true.
• The concurrent test's vi.waitFor polling is removed; cleanup is complete when the download promises settle.

---

🤖 Generated by Coder Agents

[aqandrew]

Appreciate you DRYing up the settle paths in cliManager.ts too 🙂