fix(frontend): map full beneficiary list and enforce bps allocation validation

[anonfedora]

Summary

CreateInheritancePlanPanel and EditInheritancePlanPanel only sent beneficiaries[0]?.name to plansAPI.createPlan, silently discarding every other beneficiary's wallet address, allocation percentage, and fiat off-ramp config on submission.

Digging further, the problem went deeper than the beneficiary array: plansAPI.createPlan/updatePlan sent a request shape (title, fee, net_amount, bank_account_number, bank_name, currency_preference, two_fa_code) that never matched the backend's real Plan/UpdatePlanRequest contract (see backend/src/api.rs, and the MSW mock explicitly commented "matches the Axum POST /api/plans signature"), which actually requires owner, token, amount, beneficiaries: [{address, name, allocation_bps, fiat_anchor_info}], grace_period, earn_yield, yield_rate_bps. Beneficiaries were never going to survive submission regardless of how the array was built, and inheritance.ts was missing an updatePlan() method entirely.

This PR aligns the frontend with the real backend contract end-to-end and fixes the beneficiary data loss.

Changes

• app/lib/api/inheritance.ts — added UpdatePlanRequest + updatePlan(), matching the backend's real UpdatePlanRequest (beneficiaries, grace_period?, earn_yield?, yield_rate_bps?).
• app/lib/api/plans.ts — rewrote CreatePlanRequest/UpdatePlanRequest to match the backend's actual Plan/UpdatePlanRequest structs, reusing PlanBeneficiaryRequest; createPlan/updatePlan now return the real unwrapped PlanResponse instead of assuming an {status, data} envelope that the backend never sends.
• components/plans/BeneficiaryAllocationRow.tsx (new, shared by both panels) — beneficiary row UI plus:
  • validateBeneficiaryDrafts — strict basis-point validation (allocations must total exactly 10,000 bps), Stellar StrKey checksum address validation, duplicate wallet-address detection, and fiat-field completeness checks, each with a specific error message.
  • beneficiaryDraftToRequest — builds the fiat_anchor_info JSON payload (name/currency/bank/account/daily_limit) the backend already parses on payout (parse_fiat_anchor_info).
• CreateInheritancePlanPanel.tsx:
  • Maps the full beneficiary list into PlanBeneficiaryRequest[] (address, name, allocation_bps, fiat_anchor_info) instead of dropping everything but the first name.
  • Adds a destination-asset (XLM/USDC/custom contract) field, since the backend requires owner/token and the panel previously collected neither.
  • Adds per-beneficiary fiat off-ramp fields (bank, account, currency, daily limit).
• EditInheritancePlanPanel.tsx:
  • Seeds beneficiary drafts from the plan's real beneficiaries array (wallet address, bps, parsed fiat info) instead of only a beneficiary name.
  • Sends the full beneficiary list plus real grace_period/earn_yield/yield_rate_bps on save, and merges the backend's response back into the UI's Plan shape.
  • Save button gating: allocation-total validity still gates the button (unchanged UX), while full field-level validation (name/address/fiat) now runs on save with clear inline + banner messaging.
• Updated MSW mocks (tests/mocks/handlers.ts) and two test files to match the corrected, real backend contract.

Test plan

• npm test — all 202 tests pass (npx vitest --run)
• npx tsc --noEmit — no new type errors (one pre-existing, unrelated error in tests/components/InactivityTimerCard.test.tsx predates this branch)
• npx eslint on all touched files — 0 errors (only pre-existing-style any warnings)
• npm run build (next build) — compiles and type-checks cleanly, matching CI's Frontend CI workflow gate
• Manual QA in a running app against a live backend (not exercised in this session — no backend/DB was running)

Closes #1031

🤖 Generated with Claude Code

[ONEONUORA]

Great job @anonfedora