fix(hitpay): respect zero-decimal currencies when charging and storing - #30039

What does this PR do?

• Fixes [bug]: HitPay charges JPY, KRW and VND bookings 1/100th of the configured price #30038

HitPay's payment-requests API takes amount as a decimal string in major units and echoes it
back the same way, so the integration converted in both directions — but unconditionally:

amount: payment.amount / 100,                                  // outbound  (:109)
...
amount: parseFloat(data.amount.replace(/,/g, "")) * 100,       // inbound   (:156)

The price input writes the amount through convertToSmallestCurrencyUnit, which stores
zero-decimal currencies unscaled. HitPay offers three of them — jpy, krw, vnd
(components/constants.ts) — so for those the outbound /100 undercharges by 100×: a ¥10,000
event asks HitPay to collect ¥100.

Why this went unnoticed: the two unconditional conversions cancel each other out in the
database. HitPay echoes back the 100 it was asked for, the inbound * 100 turns it into 10000, and
the Payment row plus the booker's page both display ¥10,000 — while only 1% was actually charged.
refund() throws "Method not implemented" for this app, so there is no in-app correction either.

Both lines have to change together. Fixing only the outbound conversion sends the right amount
but then stores 1000000, i.e. swaps a silent undercharge for a visible 100× overstatement:

Both directions now use the shared helpers in @calcom/lib/currencyConversions — the same module
the price input already uses, so storage, charge and display agree by construction.

Same class of bug as #29983, but an independent one in a different provider and file.

Visual Demo (For contributors especially)

No UI surface: the amount is computed server-side in the outgoing HitPay request, and because the
two conversions currently cancel out, the booking page renders the correct price both before and
after. Screenshots would be identical and prove nothing — the meaningful evidence is the outgoing
request body and the persisted amount.

Before (fix reverted, tests in place) — the three zero-decimal currencies fail, the rest pass:

AssertionError: expected { sent: '100',  stored: 10000  } to deeply equal { sent: '10000',  stored: 10000  }
AssertionError: expected { sent: '500',  stored: 50000  } to deeply equal { sent: '50000',  stored: 50000  }
AssertionError: expected { sent: '2000', stored: 200000 } to deeply equal { sent: '200000', stored: 200000 }

 Tests  3 failed | 2 passed (5)

Note stored is correct in both columns — that is the masking effect, captured as a test.

After (this PR):

 ✓ packages/app-store/hitpay/lib/PaymentService.test.ts (5 tests)

 Test Files  1 passed (1)
      Tests  5 passed (5)

Video Demo (if applicable):

N/A — no UI change.

Image Demo (if applicable):

N/A — no UI change.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox. — N/A, internal currency conversion with no documented API change.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

No HitPay credentials or environment variables are needed — the test mocks the HTTP calls and
echoes back whatever amount was requested, the way HitPay does:

TZ=UTC yarn vitest run packages/app-store/hitpay/lib/PaymentService.test.ts

To see it fail without the fix, restore the two unconditional conversions in PaymentService.ts
and re-run.

To verify manually against HitPay sandbox:

• Minimal test data: an event type with the HitPay app enabled, currency Japanese yen (JPY),
  price 10000.
• Expected (happy path): the HitPay checkout requests ¥10,000, matching the booking page and
  the Payment row. Before this change it requested ¥100 while both still displayed ¥10,000.
• Repeat with USD at price 50 to confirm unchanged behaviour: HitPay should request 50.
• krw and vnd behave like jpy; the other 18 currencies in the picker behave like usd.

Checklist