fix: secure POST /transactions/submit against third-party XDR (#117)

[Marvelg256]

🔗 Related Issue

Closes #117

🔖 Title

Secure POST /transactions/submit: wallet binding, operation allowlist, idempotency, and rate limits

📝 Description

TransactionsService.submitTransaction() previously accepted any well-formed XDR, immediately submitted it to Horizon, and recorded it against the authenticated wallet — without ever verifying that the wallet was actually a party to the transaction. This PR closes that open-relay hole:

• Source-account binding — the transaction source account (or the inner source of a fee-bump transaction) must equal the authenticated wallet, or the wallet must appear as an authorized address in the Soroban invocation auth. Third-party-sourced XDR is rejected with a typed TRANSACTION_SOURCE_MISMATCH error before any Horizon call or DB write.
• Operation allowlist per declared type — every operation must be a Soroban invokeHostFunction whose function name matches the declared type (loan_create, loan_repay, deposit, withdraw, vendor_approve, vendor_suspend) and, when configured, must target the contract owned by that flow. Mismatches are rejected with TRANSACTION_TYPE_MISMATCH / TRANSACTION_OPERATION_NOT_ALLOWED.
• Idempotency per transaction hash — a new migration adds partial unique indexes on transaction_hash and hash (with pre-existing-row dedupe); the service checks for an existing record before submitting and returns the original record (duplicate: true) instead of re-submitting, with the unique-constraint violation as the concurrency backstop. Duplicate hashes can no longer create duplicate rows or double Horizon submissions.
• Per-wallet + per-IP rate limits — a new WalletThrottlerGuard keys @nestjs/throttler on the authenticated wallet (the repo's established middleware), and the route is limited to 10 req / 60 s per wallet AND per IP via the global guard.
• Persistence-first, no silent drops — the local record is written (awaited) before the Horizon submission, so persistence failures surface as TRANSACTION_PERSISTENCE_FAILED instead of the old fire-and-forget behavior, and the transaction hash is always known to the status checker / indexer reconciliation paths.

🔄 Changes Made

• src/modules/transactions/transactions.service.ts — allowlist + source/auth validation, hash idempotency, persist-before-submit flow in submitTransaction
• src/modules/transactions/wallet-throttler.guard.ts — new per-wallet throttler guard
• src/modules/transactions/transactions.controller.ts — per-wallet + per-IP rate limits, Swagger responses updated (400 codes, 429, 500)
• src/modules/transactions/dto/submit-transaction-request.dto.ts — documents the enforced guarantees
• src/modules/transactions/dto/submit-transaction-response.dto.ts — status reflects the recorded status; new duplicate flag
• supabase/migrations/20260825000001_add_unique_transaction_hash.sql — unique indexes + dedupe
• test/unit/modules/transactions/transactions.service.spec.ts — happy path + every rejection branch (source mismatch, fee-bump inner source, allowlist/function/contract mismatch, classic ops, duplicate pre-check, unique-violation race, persistence failure, Horizon error mapping)
• test/unit/modules/transactions/wallet-throttler.guard.spec.ts — new guard tracker tests
• test/unit/modules/transactions/transactions.controller.spec.ts — compiles with ThrottlerModule
• context/progress-tracker.md — documented

🗒️ Additional Notes

• Source binding intentionally also accepts the wallet as a Soroban authorizer (not only as the transaction source) because the deposit/withdraw/repay/vendor XDR builders currently set a random source account — a strict source-equality check would reject StepFi's own two-step flows. loan_create uses the wallet as source and passes the strict path.
• transactions.repository.ts was reviewed but not modified: backfill's upsert(onConflict: 'transaction_hash') remains compatible with the new partial unique index, and findForReconciliation is unaffected.
• The migration lives in supabase/migrations/ (outside src//test/) as required by the issue and context/code-standards.md.

✅ Verification

• npm run build — zero TypeScript errors
• npm test — 30 suites / 358 tests passing (test count increased from baseline, per the mandatory checklist)
• ESLint clean on all changed files (remaining repo lint errors are pre-existing in untouched files)