feature:Status filter, shared token, live notification, contract depl…

[anonfedora]

Description

Resolves four tracked issues across the backend stream API, Redis client, SSE service, and test suite. The changes add status filtering, sorting, and pagination to the streams list endpoint; fix a Redis import incompatibility; export the SSE singleton correctly; fix a stray brace causing a syntax error in the Soroban event worker; and harden stream controller type safety and test mock fidelity.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 🧪 Test addition or update
• 🔧 Refactoring (no functional changes)

Related Issues

Closes #338
Closes #339
Closes #341
Closes #345

Changes Made

GET /v1/streams — Status filtering, sorting, and pagination (#338)

• Added status, token, sort, order, limit, and offset query parameters to listStreams
• status is validated against ['active', 'cancelled', 'completed', 'paused'] with a 400 response on invalid values; each status is mapped to the appropriate isActive database condition
• sort is validated against ['createdAt', 'startTime', 'lastUpdateTime', 'depositedAmount'] with safe fallback to createdAt
• limit is capped at 100 and defaults to 20; offset defaults to 0
• Response shape updated from a bare array to { data, total, hasMore, limit, offset } using a Promise.all count + query pattern for efficiency

Redis client fix (#339)

• Replaced ESM-style import RedisClass from 'ioredis' with const Redis = require('ioredis') to resolve the CommonJS/ESM interop issue that caused the Redis client to fail to instantiate in the deployed environment
• Updated internal types from Redis to typeof Redis throughout redis.ts to match

SSE service singleton export (#341)

• Added a named sseService singleton export alongside the existing SSEService class export in sse.service.ts
• Updated sse.service.test.ts to import both SSEService and sseService from the corrected export path, unblocking the NotificationDropdown SSE consumer

Soroban event worker syntax fix (#345)

• Removed a stray closing brace in soroban-event-worker.ts that caused an unmatched block, producing a parse/runtime error on deployment

Stream controller and test hardening

• Fixed req.params.address array guard in getUserStreamSummary to handle cases where Express provides the param as an array
• Added explicit any type annotations on .map() and .filter() callbacks in getUserStreamSummary to resolve TypeScript strict-mode errors
• Updated all stream.test.ts mock calls from bare prisma.stream.findMany.mockResolvedValueOnce to vi.mocked(prisma.stream.findMany).mockResolvedValueOnce for correct Vitest typed mock usage
• Expanded mock stream objects in tests to include all required Prisma model fields, eliminating type mismatch errors

Testing

Test Coverage

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

Test Steps

1. Start the backend locally and call GET /v1/streams?status=active&sort=startTime&order=asc&limit=5&offset=0 — verify paginated response shape with data, total, hasMore, limit, offset
2. Call GET /v1/streams?status=invalid — verify 400 response with descriptive error message
3. Verify Redis connects cleanly on startup with no TypeError: RedisClass is not a constructor errors in logs
4. Trigger an SSE event and confirm the NotificationDropdown consumer receives it via the exported sseService singleton
5. Run pnpm test — all stream and SSE unit tests should pass

Breaking Changes

GET /v1/streams response shape has changed.

Previously returned a bare array. Now returns:

{
  "data": [...],
  "total": 42,
  "hasMore": true,
  "limit": 20,
  "offset": 0
}

Migration Guide: Any frontend or client consuming GET /v1/streams must be updated to read from response.data.data (or destructure accordingly) rather than treating the response body as a direct array.

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

The status → isActive mapping currently maps cancelled, completed, and paused all to isActive: false with comments noting where event-log-based disambiguation could be added in a follow-up. This is intentional to keep the scope of this PR bounded — a separate issue should track enriching status resolution from on-chain event history once the event indexer is stable.