fix(metering): prevent double-metering on checkout retry across second boundary (#1151)

[ayomidearegbeshola29-dev]

Prevent double-metering when a checkout retry crosses a one-second boundary (#1151)

Summary

Closes #1151

PaymentIdempotencyService de-duplicates a retried checkout within a 24h window
keyed by (userId, operationType, requestFingerprint). MeteringService, however,
derived its own idempotency key as operationType-userId-<second>, so a retry that
landed in a different calendar second was correctly de-charged but incorrectly
metered twice for the same logical operation.

Root-cause fix

• MeteringService.recordUsage(...) now accepts an optional dedupKey. When
  supplied it is used as the idempotency_key (the onConflict target) instead of
  the one-second-derived key, so two calls that share a logical identity collapse to
  a single usage record.
• MeteringPaymentIntegration.reportUsage(...) now accepts a
  paymentIdempotencyKey and forwards it to recordUsage. Callers that already hold
  the payment idempotency key for the underlying checkout can now thread it through,
  making metering follow the payment layer's notion of "same logical operation"
  regardless of elapsed seconds.

Test

metered-billing-payment.checkout-retry-dedup.integration.test.ts simulates a
checkout retry (original + retry in a different second) and asserts exactly one
unique idempotency_key is produced when the payment idempotency key is threaded
through. A second case pins Date.now across a second boundary to prove the
boundary no longer matters.

Note on the companion fix

The issue references a "companion backend-scoped concurrency-cap fix". This PR is the
metering-layer half; once that concurrency cap lands, the integration test's
large-deployment scenario can be layered on top without further changes to the dedup
path.

closes #1151

[ayomidearegbeshola29-dev]

Closing as duplicate — ayomidearegbeshola29-dev PR #1190 already covers #1151/#1152. Keeping #1190.