fix: recover from Horizon bad_seq via account re-fetch, with chaos test coverage (closes #708)

[Wizdee-001]

Summary

Closes #708. Adds chaos test coverage for intermittent Horizon bad_seq
responses, and fixes a gap found while writing that coverage: the
submission retry loop was resending the same signed transaction
unchanged, which can never succeed after a bad_seq error since the
sequence number is baked into the signature.

Fix

sendTransactionWithRetry now, on a BAD_SEQUENCE classification,
re-fetches the source account via the existing getAccountWithRetry
helper and rebuilds + re-signs the transaction before retrying. If the
account can't be re-fetched (e.g. it no longer exists after a merge),
the original bad_seq failure is surfaced immediately rather than
retrying blindly.

Test coverage

• Intermittent bad_seq: pipeline re-fetches the account and the retry
  succeeds
• Persistent bad_seq: retries are bounded to the configured budget and
  the call fails loudly (throws) rather than hanging or retrying
  forever
• Stuck sequence gap (simulated account merge): re-fetch itself fails,
  and the original error still surfaces without unbounded retries

Notes

• No changes to stellarRpcFailure.ts — existing BAD_SEQUENCE
  classification and shouldRetryStellarRPCFailure budget logic were
  already correct; the gap was purely in the retry loop resending a
  stale signed transaction.
• Retry budget (maxRetries) remains the existing private field
  (default 3); happy to make it a constructor parameter in a follow-up
  if that's wanted separately.

Testing

• npm test -- stellarSubmissionService.chaos passes locally
• npm test -- --coverage run to confirm the 95% threshold

[drips-wave]

@Wizdee-001 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits