Fix NaN handling in file read limits

[pavankumar-vh]

Overview

Fix NaN handling in file read limits in common/src/util/file-read-limits.ts.

Bug Description

The function didn't validate that remainingChars and remainingTokens are finite numbers. If they were NaN or Infinity, Math.max(0, NaN) would return NaN, causing incorrect calculations.

Fix

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

Testing

No existing tests for this function, but the fix prevents incorrect behavior with invalid inputs.

Files Changed

• common/src/util/file-read-limits.ts - Added NaN validation

Scope

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

[codebuff-team]

Thanks for the contribution. The change itself is small and harmless: guarding remainingChars/remainingTokens with Number.isFinite before the Math.max calls is a reasonable defensive pattern, and it's correctly scoped to common/.

A few concerns before this is worth porting:

1. No evidence of the actual bug. The PR body describes the theoretical failure mode (Math.max(0, NaN) returning NaN) but doesn't show a call site where remainingChars/remainingTokens can actually be NaN or Infinity. If callers always pass valid numbers, this is defensive code with no real-world trigger, and the maintainers will want to know why it's needed.
2. Silently defaulting to 0 may be the wrong behavior for Infinity. If remainingTokens is legitimately Infinity (e.g. "no limit"), coercing it to 0 would incorrectly truncate everything instead of applying no limit. Treating NaN and Infinity the same way conflates two very different problems.
3. No test added. Given this is a pure bug-fix PR, a unit test exercising NaN/Infinity inputs would make the fix verifiable and prevent regression, and would also clarify intended behavior for the Infinity case.

If you can point to where invalid values originate (e.g., a division somewhere upstream producing NaN), that would strengthen the case, and fixing it at the source might be preferable to patching it here. As-is, this is the right instinct but needs a concrete justification and test coverage before it's ready to port.