fix: resolve database write collisions on StreamEvent and fix schema/syntax errors

[onajidavid87-web]

Description

Resolves critical database write collisions and unique constraint violations (P2002) occurring when the backend action controllers and the event indexer worker attempt to write the same blockchain event.

Key changes include:

1. StreamEvent Upserts: Converted StreamEvent database writes from .create() to .upsert() in withdraw, pause, and resume controllers, avoiding duplicate key collisions on @@unique([transactionHash, eventType]).
2. Restored Real-Time UI Updates: Re-enabled real-time database updates and local event logs inside the pause and resume controllers to ensure instant user feedback without relying on indexer latency.
3. Worker Duplicate Logic Fix: Updated SorobanEventWorker to only skip events if a finished event (ledgerSequence > 0) is already present. This ensures placeholder events (where ledgerSequence = 0) are properly updated with real ledger details and stream amounts are incremented correctly.
4. Schema & Compilation Fixes: Cleaned up a duplicate IndexerState model declaration in the Prisma schema and resolved a syntax error in the SSE service's client handler.
5. Integration/Regression Tests: Added a comprehensive write-race regression suite (write-race.regression.test.ts) validating controller-vs-indexer write orders, updated existing controller/worker mocks, and configured vitest to skip integration tests gracefully when a local Postgres server is unavailable.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🔧 Refactoring (no functional changes)
• ⚡ Performance improvement
• 🧪 Test addition or update

Related Issues

Closes #831

Changes Made

Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• Manual testing performed

Test Steps

Breaking Changes

Breaking Changes:

Migration Guide:

Screenshots/Demo

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published
• I have checked for breaking changes and documented them if applicable

Additional Notes