remote: a small file waits 200 ms for a job that is already done

[otsobide]

Compressing a 5 byte file on a server takes ~235 ms, against ~23 ms locally. Measured over six consecutive runs with the binary already built, all identical:

ejecucion 1:  238 ms  con 2 sondeo(s)
ejecucion 2:  234 ms  con 2 sondeo(s)
...

Almost none of that is the server. Compressing five bytes takes microseconds; the ~200 ms is a fixed sleep in the client.

Where it comes from

wait_for_completion polls once and, if the job is still queued or compressing, sleeps POLL_INTERVAL (200 ms) before asking again:

const POLL_INTERVAL: Duration = Duration::from_millis(200);
...
match protocol::progress_of(&parse_json(response)?)? {
    Progress::Ready => return Ok(()),
    Progress::Waiting => std::thread::sleep(POLL_INTERVAL),
}

The race is very tight. The server answers 202 as soon as the job is registered and the worker starts in parallel, so the client's first question usually arrives a few hundred microseconds before the worker has flipped the status to completed. It then sleeps the whole 200 ms even though the archive was ready almost immediately. One run out of six landed the other way (first poll after the flip: 28 ms, one poll, no sleep), which is what pins the cause.

So every small remote compression has a ~200 ms floor that has nothing to do with the work.

Suggested fix

Back off instead of using a flat interval: something like 10 ms, 20, 40, 80, then 200 from there on. A small file finishes in ~35 ms; a long job keeps polling as lazily as it does today.

• The fix lives in apps/remote/src/client.rs, so the CLI and the desktop app both inherit it (they share collapse-remote).
• apps/server-frontend/src/api.js has its own polling loop with the same shape and deserves the same treatment.

Not urgent

Nothing is broken: the flow is correct and the cost is bounded and constant. It is a responsiveness wart on small files, worth doing when the area is next touched.