cli: dira update re-downloads the whole archive on retry instead of resuming with Range

[azlekov]

Follow-up to #113 / #114. Low priority.

The retry added in #114 restarts each attempt from byte zero. artifact::download_once
buffers the whole body via resp.bytes() and writes once, so an abort at 10MB of 11MB
means attempt 2 re-pulls all 11MB.

That is worst exactly where the bug lives: on a lossy or TLS-inspecting link, a full
re-pull is more exposed to a second abort than a short resume would be, and each attempt
burns full bandwidth.

Suggested shape

On retry, send Range: bytes=<already-received>- and append to the partial file.

Requires switching from buffer-then-write to streaming chunks to a file handle, which is
why it was deliberately kept out of #114:

• track bytes written per attempt
• handle a server that ignores Range and replies 200 rather than 206 (start over)
• guarantee a partial file can never reach the sha256 check — the checksum verification
  is the safety net, and this changes how bytes land on disk

Priority

Low. The retry alone makes the reported incident invisible; this is an optimization for
slow or lossy links, not a correctness gap. Recorded as a known gap in
.zavet/specs/distribution-and-update.md.

[azlekov]

Considered for the v0.5 follow-up batch (#125) and deliberately left out — recording why here so it isn't re-litigated from scratch.

Why not now

• The fix(cli): retry and bound the update download, and surface repeated failures #114 retry already makes the reported incident invisible. This issue's own text calls it "not a correctness gap, an optimization for slow or lossy links", and that still reads correctly.

• It is the only item in that batch that requires artifact::download_once to stop buffering (resp.bytes()) and stream to a file handle instead. Two safety properties currently rest on the buffer-then-write shape:

  • MAX_ARTIFACT_BYTES rejects an implausible declared Content-Length before a single body byte is read;
  • the sha256 verify is the gate that a partial file can never pass.

  Streaming moves both of those onto per-chunk accounting, plus the Range-ignored-so-a-200-arrived case. That is the largest and riskiest change in the batch for the least user-visible benefit, so it was scoped out rather than rushed alongside six other fixes.

What did land (#125, closing #115): resolve::gh_get now rides the same bounded ladder as the download, so both network hops retry. The retried unit is "request and fully read the body" — the connection closed before message completed failure surfaces from the body read, after send() has already returned Ok. That covers the reported failure mode; this issue is what makes recovery from it cheaper.

Still worth doing. A full re-pull is most exposed exactly where the bug lives: on a lossy or TLS-inspecting link, re-pulling 11MB is more likely to abort again than a short resume, and each attempt burns full bandwidth. Streaming would also remove the ~20MB in-memory buffer, which is a secondary win the size cap is currently standing in for.

Recorded as a known gap in .zavet/specs/distribution-and-update.md (the *Known gap:* note under the download ladder), so the spec and the code agree that this is open by choice.