feat(connector): [ilixium] add Ilixium connector with all six core flows

[shuklatushar226]

Summary

Adds the Ilixium connector with all six core payment flows. Card, one-time payments only (3DS and no-3DS).

Flow	Endpoint
Authorize	POST /direct/auth (+ POST /direct/threedcomplete on the 3DS return leg)
Capture	POST /direct/capture
Void	POST /direct/reversal
Refund	POST /direct/refund (variant A, referencing a previous transaction)
PSync	POST /history/operations, filtered client-side
RSync	POST /history/operations, filtered to type == REFUND

Not in scope: wallets, APMs, bank transfers, mandates/MIT/recurring, tokenization, standalone refunds, disputes.

⚠️ This PR also contains a core-flow change — please review it separately

Commit 664e8abf3 is not connector code. PaymentService::authorize unconditionally required payment_method, but on a 3DS return leg Hyperswitch has no raw card data and sends payment_method_data: None, so UCS rejected the call with InvalidArgument before any connector code ran. This blocked every UCS connector that completes 3DS through the Authorize flow — which is exactly Ilixium's documented design.

The fix makes payment_method required only when redirection_response is absent, and adds a PaymentMethodData::NoInstrumentAfterRedirect variant. It touches 34 connector transformers.rs files, but only to add that variant to each one's existing unsupported-payment-method reject arm — compiler-enforced, no behaviour change when payment_method is present. A plain authorize missing payment_method is still rejected exactly as before.

There was a second gate on the same field in PaymentsAuthorizeData::foreign_try_from; relaxing only the handler would still have failed.

Design notes for reviewers

Everything is keyed off transaction.merchantRef. Ilixium publishes no gateway-id lookup, so Capture, Void and Refund all quote the original authorisation's merchantRef. The existing derive_merchant_ref helper is deterministic (verbatim when it fits [\w]{4,20}, else hex(SHA-512(ref))[..20]), so follow-up operations recompute the same reference with no persisted mapping.

Void must send the full original amount. Partial reversals are rejected with code 142. PaymentVoidData::amount is optional and every amount field on the Void PaymentFlowData is None, so a missing amount fails locally with MissingRequiredField rather than sending a zero or partial reversal — which would earn a 142 and burn an operation slot (Ilixium serialises operations per transaction, code 117).

PSync/RSync have no real endpoint. Ilixium publishes no per-payment or per-refund status query. /ipframe/apm/status is ruled out: different host (pripframev2.ilixium.com), tagged "Alternative Payment Methods", and requires a responseKey that /direct/auth never returns. So both sync flows use the bulk /history/operations reconciliation report and filter client-side. That report caps the window at 24 hours, uses a different status enum (adds EXCEPTION, VALIDATION_ERRORS) and a different transactionType enum (CNP_ECOMMERCE), and carries no paymentHistory/cardResponse. A payment outside the window cannot be synced; the caller can anchor the window via connector_feature_data.ilixium_history_period_start. No-match leaves the status unchanged and returns an actionable error rather than inventing a terminal failure.

build_headers is now generic over the flow-common-data type so the refund flows can reuse it, with connector_base_url_refunds alongside the payments helper.

Known limitations

• Refunds are not individually identifiable. The refund response carries no refund-specific id — merchantRef and gatewayRef both echo the original payment. connector_refund_id prefers status.operationRef, which the vendor documents as "available soon", and falls back to the refund's own UCS reference. While operationRef is not live, multiple partial refunds of the same amount on one payment cannot be told apart; RSync matches on amount then latest entryDate and warns when more than one candidate exists.
• customer.dateOfBirth is mandatory at Ilixium with no UCS counterpart. Sourced from merchant metadata key ilixium_date_of_birth, omitted when absent — not fabricated.
• No production base URL is documented by the vendor. All four env configs point at the sandbox host, with per-merchant override via ConnectorSpecificConfig::Ilixium.base_url.
• PSync not-found downgrades the HS status (requires_capture → processing). The connector correctly echoes the incoming status, but PaymentServiceGetRequest carries no current attempt status, so UCS defaults to Pending. Platform limitation affecting all connectors, not fixed here.
• Partial capture is not affirmatively documented by the vendor (unlike reversal, capture has no amount-mismatch error code). Implemented as pass-through.

Testing

No Ilixium credentials exist, so this is verified against a mock Ilixium server driven end to end from Hyperswitch through UCS — not against the live sandbox.

• 23+ captures audited: 0 digest mismatches, 0 schema failures. x-merchant-digest was independently recomputed from the raw received bytes on every capture, confirming Base64(SHA512(Base64(SHA512(body)) ‖ password)).
• Driven from HS /payments and /refunds: no-3DS authorize; 3DS authorize through both legs including the ACS redirect; manual-capture → Capture; manual-capture → Void; authorize → Capture → Refund → RSync; PSync.
• merchantRef consistency proven, with a negative control: a deliberately wrong reference produced code 104 "No Matching Transaction", so the passing runs are not vacuous.
• Negative paths: Void with no amount refuses locally and sends nothing; PSync/RSync no-match return ILIXIUM_NOT_IN_HISTORY_WINDOW rather than a terminal failure.
• cargo build full workspace, fmt and clippy all clean.

Requires the Hyperswitch-side PR juspay/hyperswitch#13708, which registers Ilixium for UCS routing and fixes connector_order_id being hardcoded to None on the refund path (without it, Ilixium refunds are impossible from Hyperswitch).