Resumed model download reports abnormally fast speed in Go CLI

[mengshengwu]

Background

When a model already has a partial download on disk and the user runs geniex model pull again to resume, the progress bar in the Go CLI reports an abnormally high download speed for the first few seconds.

Root cause: the bar is created lazily on the first OnProgress callback with the full total, then immediately fed the cumulative downloaded count — which includes bytes already present on disk. schollz/progressbar/v3 starts its rate counters at bar-creation time, so that large jump lands entirely inside its rolling-rate window (~0.5s) and inflates the reported speed.

• cli/cmd/geniex/model.go:439-452 — OnProgress sums f.DownloadedBytes (already-on-disk bytes included) and calls bar.Set(downloaded) on a freshly-created bar.
• cli/internal/render/progressbar.go:19-43 — thin wrapper around github.com/schollz/progressbar/v3 v3.18.0, no offset knob available.

The Python binding had the same bug and was fixed in #1190 by seeding tqdm with initial=downloaded_bytes (tqdm's built-in offset). schollz/progressbar has no equivalent today; a feature request and reference implementation are open upstream at schollz/progressbar#231 / PR #232. Once merged and released, we can bump the dep and mirror the Python fix in the CLI.

Goal

Make the reported download speed in the Go CLI reflect only bytes transferred in the current session, so resuming a partial download shows a realistic rate. Blocked on the upstream schollz/progressbar change landing.