[Backend] Remittance submit has a check-then-act race that allows double submission

[grantfox-oss]

Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0

Why this matters

src/controllers/remittanceController.ts submitRemittanceTransaction reads status then later calls updateRemittanceStatus (lines 147-158) with no row lock or idempotency. Two concurrent submits both see status 'pending', both submit the signed XDR to Stellar, and the route has neither validateBody nor idempotencyMiddleware.

Acceptance criteria

• Make the pending->processing transition atomic (conditional UPDATE ... WHERE status='pending' RETURNING, or SELECT FOR UPDATE in a transaction)
• Add a zod body schema and validation middleware for the submit route
• Apply idempotencyMiddleware to the submit route consistent with loan/pool submit
• Add a test asserting concurrent submits result in exactly one Stellar submission

Files to touch

• src/controllers/remittanceController.ts
• src/routes/remittanceRoutes.ts
• src/services/remittanceService.ts
• src/schemas/remittanceSchemas.ts

Out of scope

• Changing the remittance state machine
• Adding new remittance statuses

[GBOYEE]

Hi — the check-then-act race in submitRemittanceTransaction (reads status, then updates with no lock/idempotency) is a double-spend risk on real Stellar funds, so it's worth fixing properly. I can add an idempotency key + row lock (or optimistic concurrency) around lines 147-158 so concurrent submits can't both go through. Happy to take this if it's still open.