Report actual download time for a fetched payload, not time to first response #707

Problem

✓ Downloaded: <alias> <kind> (Xs) does not report how long the download took. The timer stops when response headers arrive; the body streams afterwards and is never measured.

Two symptoms of the same cause:

• A 430MB file payload printed (0s)
• The same figure swings between runs of the same unchanged file — 0s, 1m 18s, 1m 45s — because what it actually measures is how long Figma took to begin responding, which varies with origin-side serialization

Timing is the only signal of how long a large fetch takes, so it misleads exactly where it is needed: diagnosing a slow or failing download. The wait for Figma to start responding and the transfer itself have different causes and different remedies, and today neither is reported.

Potential solution(s)

• Stop the timer when the payload is complete on disk
• Report the wait for Figma to begin responding separately from the transfer
• Report bytes and throughput alongside elapsed for a streamed payload

Acceptance criteria

• The elapsed figure covers the transfer through the last byte written
• A multi-hundred-MB payload never reports a sub-second download
• Time spent waiting for Figma to begin responding is visible, rather than silently folded into a number labelled as download time

Case data

• Workspace: fm — during a fetch
• Territory: cli
• Impacted file(s): packages/cli/src/commands/FetchCommand.ts
• Size: xs

Notes

Found while diagnosing an intermittent transport drop on a large file payload. The misreported timing actively obstructed that diagnosis, since it gave no indication of how long the socket was actually held open.

Implementation details are tracked internally.