Hosts: top-ups, payment requests and balance over TrUAPI #1268

The host serves the core's top-up, payment and balance callbacks from the engines it already has.

• Call the existing services, don't build new ones:

  • iOS: IncomingPaymentService, ExternalPaymentService, CoinageBalanceService
  • Android: RealTopUpService, RealExternalPaymentService, TotalBalanceUseCase

• set_top_up_callbacks: accept a ProductAccount, PrivateKey or Coins source; status by id through notify_top_up_status; ids scoped per product

• set_payment_callbacks: approval and privacy sheets as today; status by id through notify_payment_status; AlreadyExists for a reused id

• set_balance_callbacks: report what a payment can spend (availablePrivate + gainingPrivacy); iOS reports total today. The core asks for BalanceAccess; the host only shows its existing prompt

• One acknowledgement loop: keep the ClaimedPartially / NotClaimed sheets, triggered from the engines as today

• Once TrUAPI is the default runtime, remove the legacy bridge payment handlers:

  • iOS: the five payment handlers in ContainerBridge+HostApi.swift (paymentBalanceSubscribe, paymentRequest, paymentStatusSubscribe, paymentTopUp, paymentTopUpStatusSubscribe) and their JS side in product-container/src/index.ts. The rest of that bridge stays until the legacy runtime is retired
  • Android: PaymentHostCalls.kt and its registration in HostCallGroupFactory

• Engines move to the core later: Move the top-up and payment engines into the core #1330

• iOS

• Android

Done when A product's top-up, payment and balance work over TrUAPI on both platforms, with the same statuses and errors as the legacy bridge.
Depends on #1314
Refs #778 · #969