Non-Custodial Partner Program — partner statistic completion funnels

[joshuakrueger-dfx]

Why

Stacked on #4538 — merge that one first, otherwise this PR's diff pulls the aggregates in with it.

Adds the two completion funnels: how many payment-info requests turn into an actual payment, and how
many received payments are delivered rather than stalling.

Honest scope note

Cake did not ask for this. Their request named volume, user counts and popular coins — all covered
by #4538. These metrics were requested internally, and the only figures I have are global rather
than per partner: in 2026, 222,400 payment-info requests against 17,179 actual payments. Whether
that ratio looks different for any individual partner cannot be answered until this endpoint exists.
Reviewers should weigh the review cost against that.

What

completion: {
  paymentInfoRequests: { buy|sell|swap: { requested, paymentReceived, waitingForPayment,
                                          noPaymentReceived, receivedRate } },
  settlement:          { buy|sell|swap: { received, delivered, rejected, inProgress,
                                          deliveredRate } }
}

Two funnels, deliberately not multiplied into one number — they have different denominators.
Globally stage A sits near 7% and stage B near 96%; a single combined figure would mean nothing.

Stage A is not a conversion rate and is not labelled as one. A transaction_request row is
created on every payment-info call, so on every amount change in the frontend — not once per
purchase intent. The field names and @ApiProperty descriptions say so explicitly.

Both funnels are additive by construction (requested is the sum of the three statuses;
inProgress is defined as received − delivered − rejected), so a per-cell suppression would
disclose the hidden member by subtraction. They therefore use the block suppression introduced in
#4538: if any member falls below the threshold, the whole funnel object is suppressed.

settlement.received counts all rows while totals.transactions in #4538 counts only AML-passed
ones. That difference is intentional and documented on the DTO — a dashboard summing them will not
reconcile.

Verification

• Suite in four shards on the combined stack: 333 suites, 6113 tests, 0 failures. lint empty,
  format:check clean, tsc --noEmit clean.
• Statistic specs green under four process timezones.
• Mutation probes: block suppression removed → red; per-direction timeline threshold reverted → red;
  distinct-user threshold removed → red.
• The base commit in Non-Custodial Partner Program — aggregated partner statistics endpoints #4538 builds and passes on its own, verified by checking it out in isolation.