stellar.service.ts: retry logic reuses stale transaction object — sequence number may be out of sync
invokeContract retries with MAX_ATTEMPTS=3 and re-fetches the account to get a fresh sequence number. However, if the first attempt partially succeeds (tx submitted but response lost), the retry builds a new tx with a different sequence, and both land on the blockchain.
Acceptance criteria:
- After each failed attempt, check if the tx actually landed on chain before retrying
- Use a unique client-side ID (timestamp + random) to detect duplicates
- If a duplicate is detected, return the original txHash instead of submitting again
stellar.service.ts: retry logic reuses stale transaction object — sequence number may be out of sync
invokeContract retries with MAX_ATTEMPTS=3 and re-fetches the account to get a fresh sequence number. However, if the first attempt partially succeeds (tx submitted but response lost), the retry builds a new tx with a different sequence, and both land on the blockchain.
Acceptance criteria: