core: implement Stellar sequence-number management for concurrent submission

[EmeditWeb]

Problem

Server-submitted transactions (loan funding, default detection job, admin
operations) are all sent from the protocol source account via
blockchain.service. Each submission fetches the account sequence number
from Horizon independently. When two submissions run concurrently — e.g. the
hourly default-detection job overlapping an admin call — they read the same
sequence number and the second transaction fails with tx_bad_seq. There is
no serialization, channel-account pool, or sequence allocator, so throughput
is capped at one in-flight transaction and collisions fail silently.

Before Starting

Read ALL of these before writing any code:

• context/architecture-context.md
• context/code-standards.md
• context/progress-tracker.md

What To Build

A sequence-number manager for the protocol signing account:

1. Serialize submissions from the source account through a single allocator
   that hands out monotonic sequence numbers and re-syncs from Horizon on
   tx_bad_seq or restart.
2. Optionally support a pool of channel accounts to allow concurrent
   in-flight transactions without collisions.
3. Integrate with the existing submit/status-checker flow and expose metrics
   (in-flight count, bad-seq retries).

Files To Touch

• src/blockchain/* (sequence manager / channel pool)
• src/jobs/transaction-status-checker/*
• src/modules/blockchain/*
• corresponding *.spec.ts

Acceptance Criteria

• Concurrent submissions no longer collide with tx_bad_seq
• Sequence allocator re-syncs from Horizon on failure/restart
• Optional channel-account pool enables concurrent in-flight txs
• Metrics exported for in-flight count and bad-seq retries
• Concurrency test proves ordered submission under parallel callers

Mandatory Checks Before Opening PR

• All context/ files read and understood
• context/progress-tracker.md updated
• npm run build passes with zero TypeScript errors
• npm test passes — test count not decreased
• No new any types introduced
• Swagger decorators on any new endpoint
• Migration file created for any schema changes
• PR references this issue number

[Lanhubs]

I can take ownership of this issue. Eliminating race conditions and handling sequence allocation safely under concurrent loads is an essential part of my backend and blockchain engineering workflow.

Proposed Implementation Strategy
Sequence Allocator & Synchronization: I will build an in-memory sequence-number manager inside src/blockchain/ that serializes sequence generation using a mutex or an atomic counter. On initialization or whenever a tx_bad_seq failure occurs, the allocator will fetch the absolute latest sequence number from Horizon and lock it in before handing out subsequent values.

Channel Account Pool Support: To increase throughput and enable safe parallel operations (allowing admin calls and cron jobs to process concurrently), I will implement a pool of channel accounts. The manager will check out available channel accounts as the transaction source, bypassing sequential limitations on the master protocol account.

Metrics & Monitoring: I will expose operational telemetry fields tracking active in-flight transactions, resource utilization, and bad-sequence recovery/retry events.

Concurrency Testing: I will craft parallel unit and integration tests using Promise.all to spin up overlapping callers, verifying that the allocator gracefully serializes or distributes execution paths without leaking any unhandled collisions or dropping existing test count limits.

[ebubeb683-ship-it]

I have experience using React, I have looked through the project’s code, and I can submit a Pull Request (PR) with the fix within 2 days.