refactor: extract shared Decimal→BigInt conversion helper

[lekescrew22]

Closes #107
Closes #108
Closes #109
Closes #110

Summary

Two modules converted a Prisma Decimal amount to a BigInt via .toFixed() — and both carried the same multi-line comment explaining why that's necessary: Decimal.toString() switches to exponential notation past 21 significant digits, so BigInt() can't parse an i128::MAX-sized amount (39 digits) rendered as "1.7...e+38". The analytics reader's copy even pointed back at the escrow repository's, meaning the next module to touch an amount would have to rediscover the pitfall — or trip over it.

This PR extracts that knowledge into a single shared helper so it lives in exactly one place.

Changes

• src/shared/database/decimal.ts (new) — decimalToBigInt(value: Prisma.Decimal): bigint, with the exponential-notation explanation as its doc comment. Placed in shared/database alongside the other Prisma concerns.
• src/shared/database/decimal.spec.ts (new) — unit tests: small values, zero, negatives, and the 39-digit i128::MAX case that .toString() renders exponentially.
• src/shared/database/index.ts — exports the new helper.
• src/modules/escrow/infrastructure/prisma-escrow-repository.ts — toDomain uses decimalToBigInt; duplicated comment removed.
• src/modules/analytics/infrastructure/prisma-analytics-reader.ts — getGmvByToken uses decimalToBigInt; the comment pointing at the escrow file removed. A null _sum.amount (empty group) still maps to 0n, matching the previous ?? '0' behavior.

Why .toFixed() and not .toString()?

Verified against Prisma's Decimal (decimal.js) with the real i128::MAX value 170141183460469231731687303715884105727:

Method	Output
.toString()	1.70141183460469231731687303715884105727e+38 → BigInt() throws SyntaxError
.toFixed()	170141183460469231731687303715884105727 → parses cleanly

Testing

• decimal.spec.ts: 4/4 pass.
• tsc --noEmit: no errors in any file touched by this PR.
• The escrow/analytics integration specs exercise these code paths but require a database and were skipped locally.

Note: pnpm typecheck and the full pnpm test suite currently fail on main with pre-existing errors in unrelated files (stale fixtures, env config keys, error-handler specs, etc.). Reproduced the identical failures with this change stashed to confirm they're not introduced here.

[drips-wave]

@lekescrew22 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits