[INTERNO] Endurecer manejo de errores y race conditions en flujos de escrow

[MarxMad]

Contexto

Los flujos de claim-provider/[id] y claim-investor/[id] tienen edge cases que pueden dejar facturas en estado inconsistente:

• Usuario firma la transacción de release pero la red la rechaza después → la UI marca como liberada, on-chain no lo está.
• Dos pestañas abiertas reclamando a la vez.
• PATCH /api/invoices/[id] falla después del release on-chain → escrow liberado pero DB no actualizada.
• Errores de Freighter (user rejected, network mismatch) muestran stack traces.

Alcance

• Implementar patrón "on-chain first, db second" con reconciliación:
  • Antes de actualizar DB, verificar tx con server.getTransaction(hash) y esperar SUCCESS.
  • Si DB update falla, encolar retry idempotente (no liberar de nuevo).
• Idempotencia en endpoints PATCH (header Idempotency-Key).
• Lock UI mientras una tx está pendiente (disable botones, mostrar estado).
• Mapeo de errores Stellar/Trustless a mensajes accionables (#6 provee el catálogo, este issue cablea la lógica).
• Tests unitarios de los reducers de estado de factura.

Por qué NO se delega

Lógica de dinero. Un bug aquí = facturas perdidas o doble pago.