Fix NaN handling in getFreebuffStreakLine

[pavankumar-vh]

Overview

Fix NaN handling in the getFreebuffStreakLine function in common/src/util/freebuff-streak-line.ts.

Bug Description

The function didn't validate that streak is a finite number. If streak was NaN or Infinity, Math.min(NaN, 7) would return NaN, and chars.filled.repeat(NaN) would throw a RangeError.

Fix

Added Number.isFinite() check to default to 0 for invalid numbers.

Testing

No existing tests for this function, but the fix prevents runtime errors with invalid inputs.

Files Changed

• common/src/util/freebuff-streak-line.ts - Added NaN validation

Scope

This change only touches common/ which is an approved contribution area per the Contributing Guide.

[codebuff-team]

Good catch — Math.min(NaN, 7) propagating into repeat(NaN) is a real crash, and the fix in common/src/util/freebuff-streak-line.ts is minimal and in-scope.

A few things worth tightening before this is ported:

1. Negative streaks still break. Number.isFinite(-5) is true, so safeStreak stays -5, filled becomes -5, and chars.filled.repeat(-5) throws a RangeError just like the NaN case did. If the goal is to make this function robust to bad input, clamping to >= 0 as well (e.g. Math.max(0, Number.isFinite(streak) ? streak : 0)) would close that gap in the same pass.
2. No test added. This is a pure function with no existing coverage, which is exactly the kind of place a one-line Vitest case (getFreebuffStreakLine(NaN, ...), getFreebuffStreakLine(-1, ...), getFreebuffStreakLine(Infinity, ...)) would make the fix self-evidently correct and prevent regression.
3. Minor: consider whether callers should ever legitimately pass NaN/Infinity, or whether this should be validated at the caller boundary instead — but defaulting defensively inside the formatter is a reasonable place too.

Substance is right, scope is right, but I'd like to see the negative-number case and a test before this gets ported as-is.