feat: #/pay-email — send payment via email (provider-held UTXOs)

[AquiGorka]

Step 2 of the demo surface (ClickUp 86caeh3a1, parent 86caq47uw). Builds on #7 (base branch is entity-sep10-login so this diff is step-2 only).

Design (as specified by Gorka)

Send [asset] [amount] to [email]: the backend derives holding UTXO keys of its own — deterministically from the PP secret + the recipient email, indexed from 0 — and the payer CREATEs onto them. The funds sit in provider custody until whoever KYC-registers with that email signs in: they then appear in that entity's balance and are spendable/withdrawable as if their own (the client submits their SPENDs unsigned; the provider recognises its holding keys and signs server-side, transparently). No storage, no claim step: derivation is the attribution, and unused keys are found by chain-scanning from index 0 (same -1/0/>0 conventions as the frontend sweep). Works for emails nobody has registered yet.

The KYC field stays DB column name — only the registration form legend/input changed to "Email" (POC, it's just a string).

Changes

Backend

• crates/core/src/holding.rs — deterministic P-256 holding-key derivation + AuthPayload preimage/signing (client-parity construction: contract strkey ‖ conditions ScVal XDR ‖ LE32(exp); ECDSA P-256/SHA-256, low-S, raw r‖s)
• crates/core/src/mlxdr.rs — unsigned_spend_utxo (detect unsigned spend slots) and sign_spend_slot (sign + re-encode, conditions taken verbatim from the slot)
• GET /api/v1/provider/entity/holding/targets?email=&channel=&count= — never-used holding pubkeys for an email (the payer's CREATE targets)
• GET /api/v1/provider/entity/holding?channel= — funded UTXOs held for the authed entity's registered email
• Submit path — unsigned SPENDs must match the submitter's own email-derived holding sequence (else 400); matched ones are signed in place before classification, so the pipeline and executor see a fully signed bundle

Frontend

• #/pay-name — mirrors #/pay-utxo: same login ceremony (SEP-10 + seed derivation, zero persistence), KYC banner, then Balance, Send (asset + amount + email), Deposit, Withdraw. No Request section. Balance shows own + held (held total annotated). Send/Withdraw draw on held UTXOs transparently.
• moonlight-client.ts — fetchHeldUtxos / submitSendToEmail; submitWithdraw gains an optional held pool (default [], #/pay-utxo unchanged); shared cross-pool selection + spend building
• KYC form legend "Legal name" → "Email"

Verification

cargo test --workspace green (holding derivation/signing unit-tested), deno task build/lint/fmt green (pre-existing deno task check breakage on main untouched). End-to-end on the local stack (script: task tmp stack/local-dev/verify-pay-name.ts): payer registers with email + SEP-10 → deposits 5 XLM → gets a holding target for a not-yet-registered email → sends 2 XLM (COMPLETED on-chain) → recipient registers with that email → sees the 2 XLM held UTXO → withdraws with the held SPEND submitted unsigned → provider signs it server-side → COMPLETED, recipient wallet +1.9 XLM. The Rust-side P-256 signed-payload encoding verifies against the soroban-core 0.5.0 contracts.

Notes

• Custody tradeoff is the point of the demo: the provider can spend held UTXOs (it owns the keys) and learns the email→payment linkage; the recipient's remainder migrates to self-custody on their first spend (change goes to their own derived keys).
• POC caps: 200-key scan ceiling per email; email matched as exact registered string; already-APPROVED entities registered without a name/email have no way to set one (pre-existing post_register early-return, untouched).