Fix division by zero in currency conversion functions

[pavankumar-vh]

Overview

Fix a potential division by zero bug in currency conversion functions.

Bug Description

Both convertCreditsToUsdCents and convertStripeGrantAmountToCredits would produce Infinity or NaN when centsPerCredit is 0 or negative:

• convertCreditsToUsdCents: Would return 0 * Infinity = NaN or Infinity * credits = Infinity
• convertStripeGrantAmountToCredits: Would return amountInCents / 0 = Infinity or NaN

Fix

Added guards to return 0 when centsPerCredit <= 0, which is the safest behavior (no conversion possible when the rate is invalid).

Testing

No existing tests for these functions, but the fix prevents undefined behavior.

Files Changed

• common/src/util/currency.ts - Added division by zero protection

Scope

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

[codebuff-team]

Thanks for digging into common/src/util/currency.ts — division-by-zero and negative-rate guards are a sensible thing to think about in conversion utilities.

The concern with this specific fix is the failure mode: silently returning 0 credits/cents when centsPerCredit is invalid is dangerous in a money-conversion path. If centsPerCredit is ever 0 or negative due to a misconfiguration or bad Stripe price setup, you'd rather that be loud (thrown error, logged warning, or an assertion) than silently converted into "zero cost" or "zero credits granted" — either could quietly break billing in either direction (undercharging or granting no credits) without anyone noticing. Silent-zero is arguably worse than the current NaN/Infinity behavior, which at least tends to produce visibly broken output that gets caught in QA rather than a plausible-looking but wrong 0.

A few things I'd want addressed before this is portable:

• Confirm how centsPerCredit is actually produced/validated upstream — is <=0 even reachable in practice, or is this purely defensive? If it's genuinely reachable, that call site probably needs the real fix.
• Consider throwing (throw new Error(...)) instead of returning 0, so callers can't silently proceed with bad math.
• Add unit tests for both functions (zero, negative, and normal rates) since the PR itself notes none exist — for a currency function this is the first thing a maintainer will ask for.

Good instinct, but the chosen fallback behavior needs more thought given this touches money calculations.