fix(client): ignore NaN in setDownloadProgress instead of storing it

[jeffrey701]

Problem

setDownloadProgress (client/src/pwa/updateStatus.ts) documents a 0–100 clamp, but NaN escapes it: Math.max/Math.min propagate NaN, and the downloadProgress === clamped change guard never trips (NaN !== NaN), so NaN is stored and pushed to listeners. BuildBadge then renders "NaN%" and style={{ width: "NaN%" }} (invalid CSS), and each subsequent NaN re-notifies every listener.

NaN is exactly the receivedBytes / totalBytes * 100 result when a download reports no content-length — tauriUpdater.ts reads event.data.contentLength ?? 0, so totalBytes can be 0. That caller already had to add a totalBytes > 0 workaround; the utility should defend its own documented contract rather than rely on every caller to guard.

Fix

A Number.isNaN(value) early return that keeps the last valid progress. Every finite value and ±Infinity still clamp correctly (Infinity→100, -Infinity→0) — only NaN is rejected.

Tests

Adds the module's first test: the clamp/rounding, ±Infinity, and the NaN case (which fails without the guard — discriminating, seeded with a known value so it is immune to singleton state). tsc -b --noEmit and eslint clean.

Self-contained: only updateStatus.ts + a new test; no engine/Rust/protocol changes.

Model: claude-opus-4-8

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!