Fix NaN/Infinity handling in responseAdDisplayCount with tests

[pavankumar-vh]

Overview

Fix NaN/Infinity handling in the responseAdDisplayCount function in common/src/util/lazy-response-ads.ts with comprehensive test coverage.

Bug Description

The function used Math.floor() without checking if the input was a valid number. If params.eligibleCount or params.poolSize was NaN or Infinity, Math.floor() would return NaN, and Math.max(0, NaN) would return NaN, causing incorrect results.

Fix

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

Testing

Added comprehensive test coverage with 8 test cases:

1. Returns eligibleCount when poolSize is at or above the max
2. Clamps to poolSize when poolSize is below the max
3. Returns 0 when eligibleCount is NaN
4. Returns 0 when poolSize is NaN
5. Returns 0 when eligibleCount is Infinity
6. Returns 0 when poolSize is Infinity
7. Returns 0 when both inputs are negative
8. Floors fractional inputs

All 8 tests pass.

Files Changed

• common/src/util/lazy-response-ads.ts - Added NaN/Infinity validation
• common/src/util/__tests__/lazy-response-ads.test.ts - New test file with 8 test cases

Scope

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

[codebuff-team]

Thanks for the clean, focused patch. The fix itself is correct: Math.max(0, Math.floor(NaN)) does propagate NaN through to the caller, and your Number.isFinite guard resolves that cleanly. The 8 test cases are well-organized and cover the boundary/negative/fractional cases along with the NaN/Infinity paths you're fixing.

One thing worth clarifying in the PR description for the maintainer's benefit: where do eligibleCount and poolSize actually originate upstream (e.g. array.length, a config value, a computed ratio)? If they're always derived from .length or integer counts, this defensive check may never trigger in production, and it'd help reviewers to know whether this is closing a real observed bug vs. hardening against a hypothetical input. That context doesn't block the fix - it's low-risk, additive, and doesn't change existing behavior for valid inputs - but it affects how urgently it gets ported vs. queued.

Minor style nit: consider running this through the repo's formatter (some lines exceed the project's typical line-length conventions, e.g. the safeEligibleCount/safePoolSize declarations could wrap to match existing style in the file).

Overall this is the right shape for a common/ contribution: small, scoped, tested, and doesn't touch anything out of bounds.