fix(pb): make disableProgress race-free with sync/atomic.Bool

[SAY-5]

What

internal/pb/pb.go:33-40 declares a package-level disableProgress bool that gets written by SetDisableProgress(disable bool) and read from the progress-bar hot path inside (*ProgressBar).Add:

var (
    disableProgress bool
)

func SetDisableProgress(disable bool) {
    disableProgress = disable
}

// ... later
if disableProgress {
    return reader
}

Multiple concurrent pull/push workers call Add from their goroutines while the main goroutine (CLI arg parsing, feature flags, etc.) may still flip disableProgress. The access is unsynchronised, so per #493 go test -race reports a data race, and the Go memory model leaves the behaviour undefined in practice.

Fix

Use sync/atomic.Bool:

var (
    disableProgress atomic.Bool
)

func SetDisableProgress(disable bool) {
    disableProgress.Store(disable)
}

// ... later
if disableProgress.Load() {
    return reader
}

No public-API change — SetDisableProgress(bool) keeps the same signature. Callers and tests continue to pass a plain bool; the race-detector reports clean.

Fixes #493

[gemini-code-assist]

Code Review

This pull request converts the disableProgress flag to an atomic.Bool to ensure thread-safe access across concurrent goroutines, specifically for pull/push workers. It updates the SetDisableProgress and Add methods to use atomic operations. I have no feedback to provide.

[chlins]

lgtm