[PBI] Integration tests and end-to-end validation

[cjlapao]

Description

Write a comprehensive integration test suite that covers the full notification lifecycle from dispatch through persistence, WebSocket delivery, and REST retrieval. This is the safety net that confirms all PBIs work correctly together as a system before the feature is considered shippable.

User Story

As a backend engineer preparing to ship the notification feature, I want a suite of integration tests that exercise the complete flow from emission to delivery, so that I can merge with confidence and catch any regressions introduced by future changes.

Acceptance Criteria

• Full lifecycle test: Emit a notification via the dispatcher → verify the row exists in the database → verify the WS message was delivered to a mock connected client → verify the REST API returns the notification.
• Fan-out test: Emit a system fan-out notification → verify one row was created per target user → verify only the correct user's row is returned via the API.
• Explicit targeting test: Emit with target_users = [userA] → verify userB has no row.
• Correlation group test: Emit an alert and a success with the same correlation_id → verify the correlation filter returns both, in creation order.
• Offline user test: Emit a notification for a user with no active WS connection → verify no error is raised and the row persists correctly for REST retrieval.
• Read lifecycle test: Create notification → verify is_read = false → mark as read → verify is_read = true → verify unread count decremented.
• Delete test: Create notification for userA and userB with same correlation → userA deletes theirs → verify userB's row is unaffected.
• Action round-trip test: Emit a notification with one navigate and one api_call action → verify both are returned correctly via REST and WS.
• CI integration: All integration tests run in CI against both SQLite (in-memory) and PostgreSQL (Docker container).

Definition of Done

• Code implemented following best practices.
• Unit tests written and passing.
• Code reviewed and approved.
• Merged into the main branch.
• Documentation updated (if applicable).
• Deployed to staging/production environment.

Assumptions and Constraints

• Assumption: A test harness for spinning up a real (or in-memory) database and a mock WS hub already exists from the database migration feature work.
• Constraint: Integration tests must not require external services beyond the database. WS hub is tested with an in-process mock.

Dependencies

No response

Additional Notes

No response