Current download/upload speed always displays "0 B/s" while sparkline and peak show real traffic

[kajka]

In the hero view (and likely compact/mini as well), the live "current speed" readout for both download and upload consistently shows 0 B/s, even while active network traffic is clearly ongoing. This is visible at the same time as:

The sparkline/waveform graph, which correctly renders a full history of non-zero throughput.
The "peak" value, which correctly reflects a high recorded value (e.g. 33 MB/s peak download, 148 KB/s peak upload in my case).

So the historical graph and peak tracking both confirm that real traffic is being measured and recorded, but the large numeric "current" value at the top of each panel does not reflect it and instead stays pinned at zero (or intermittently flickers near zero) regardless of actual throughput.

Steps to Reproduce

1. Run flow in hero mode on a machine with active, sustained network traffic (e.g. a large download in progress).
2. Observe the download/upload panels.
3. Note that the numeric "current" value shown next to the download/upload labels reads 0 B/s, while the sparkline graph beneath it is fully populated with non-zero activity and the "peak" value on the right is clearly non-zero.

Expected Behavior
The current speed readout should track actual throughput in real time, consistent with what the sparkline and peak values already show.

Actual Behavior
The current speed readout is stuck at (or repeatedly collapses to) 0 B/s, disconnected from the real sampled data that is clearly being captured correctly elsewhere in the UI (sparkline, peak, daily totals).

Environment

• OS: macOS 27 Developer Beta 6
• Terminal: tmux session (screenshot attached below)
• Interface: en0
• View mode: hero
• Version: 0.2.1 (installed via home-brew)

Additional Notes

• The daily totals ("today ↓ 12.8 GB ↑ 107.4 MB") also look plausible and non-zero, reinforcing that the underlying sampling/collection is working — this appears to be isolated to whatever value is used to render the large "current speed" number specifically.
• This makes the tool effectively unusable for its core purpose (seeing current throughput at a glance), since the one number meant to answer "what is my network doing right now" is the one that's wrong.

[programmersd21]

Fixed in #30 — root cause: the spring animation used a damping factor 1 - damping*dt which goes negative at the 130ms UI tick rate (1 - 12*0.13 = -0.56), so the animated speed value diverged to deep negative numbers every tick and FormatBpsExt clamped them to 0 B/s. The sparkline/peak read raw history samples, which is why they looked correct. Fix switches to exp(-damping*dt). Also bumps version to 0.2.2.