[miguel-heygen]

What

Follow-up to the cloud upload change that already merged: its progress and slow-server tests flaked, its retry loop was over the complexity limit, and the "same cut twice" rule compared bytes that vary from run to run.

• Two tries cut at about the same age (within 20%) now count as the same cut whatever bytes each got through; the byte count of a try varies with the link, the age of a fixed-age cut does not.
• The retry loop's cut decision moves into repeatedCut; the test server's body reading into drain, so fallow audit no longer flags putWithRetry and the test server.
• Progress is sampled on its own interval (putTimings.sampleMs, 1 s by default) and no longer on the stall interval, so a try that dies in under a second still reports the bytes it sent.
• The slow-server tests drain at a fixed rate whatever the chunk size and use a stall limit long enough that their own timing cannot trip it.

Why

upload.test.ts failed 1 run in 5 on the progress test and about 1 in 2 on the identical-cut test under load. Root causes: the stall watcher also drove the progress sampling (so a short try reported 0 bytes), the cut test compared byte counts across tries (kernel buffering varies), and the test server's drain rate depended on the chunk size the kernel handed it.

Size

A follow-up in the same module and its test, tied to one root (the flaky timing in the upload tests); nothing else touches them.

Test plan

• cd packages/cli && npx vitest run src/cloud/upload.test.ts: 20 passed, 6 runs in a row, on a clean checkout; oxlint and oxfmt clean on both files.
• fails without the fix: the cut test fails on main's upload.ts (it keeps retrying four times when the bytes differ between tries).
• fallow audit --base origin/main reports no new finding in the two files.