[327] Resolve race conditions in concurrent database_writer_pool calls

[Goodnessukaigwe]

Summary

• Add an in-memory WriterPoolEventQueue with per-event identity locks (contractId|ledgerSequence|eventType) so concurrent database_writer_pool notifications cannot both observe "not indexed yet" and insert the same row.
• Duplicate prevention happens in two layers: the queue drops already-pending/already-persisted keys before persist, then each identity is drained under a lock that checks the persisted-key set again. Default persist goes through queueWrite + INSERT OR IGNORE. Unrelated identities still persist concurrently; locks are always released on success and failure.
• Concurrent queueWrite of unrelated operations remains on the existing sequential SQLite writer queue (one writer at a time) and is not serialized by event locks.

Closes #327

Test plan

• New __tests__/database-writer-pool-concurrency.test.ts: concurrent submits insert each event once; same-key persists never overlap; unrelated keys run in parallel; lock released after success and after persist throw; overflow / reset / repeated waves.
• SQLite store: concurrent submitEventNotifications of the same window do not duplicate rows; sequential resubmits are idempotent; store-level INSERT OR IGNORE still de-duplicates after a queue reset; racing queueWrite inserts do not double-count.
• Concurrency suite run 3 times in a row (28/28 each run).
• Existing database-writer-pool* tests (91/91).
• tsc -p tsconfig.build.json and npm run build.

Made with Cursor

[drips-wave]

@Goodnessukaigwe 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