fix: guard division by zero in ETA calculation when rate is zero

[AdamMagued]

Root Cause Analysis

When predictTime is enabled and averageRate <= 0 (such as when rendering a blank state before transfers begin or when no progress has elapsed), 1 / averageRate performs a floating-point division by zero yielding +Inf (or NaN if c.max == s.currentNum).

According to the Go specification, converting a floating-point value that cannot be represented by the target integer type is implementation-dependent. Converting +Inf to time.Duration (an int64) produces different values across hardware architectures:

• On x86 architectures, the conversion yields math.MinInt64 (-9223372036854775808). In 64-bit integer arithmetic, -9223372036854775808 * 10^9 = 0 (mod 2^64), masking the division by zero.
• On non-x86 architectures such as ARM64, the conversion saturates to math.MaxInt64 (9223372036854775807). Multiplying by time.Second (10^9) wraps to -1000000000 (-1s), producing unexpected negative ETA values and failing tests.

Solution

Guard the ETA computation:

• Check averageRate > 0 before evaluating (1/averageRate)*(float64(c.max)-float64(s.currentNum)).
• When averageRate <= 0, rightBracNum defaults to 0 * time.Second (0s).
• Keep the existing negative duration clamp to safeguard cases where s.currentNum > c.max.

Testing

• Added unit regression test TestPredictTimeZeroRate in progressbar_test.go verifying both zero rate and negative rate conditions.
• Ran full test suite (go test -v ./...) with 100% passing tests.

Fixes #103