[PBI] WebSocket notification delivery

[cjlapao]

Description

Integrate the notification dispatcher with the existing WebSocket hub so that a newly created notification is pushed in real time to any connected session belonging to the target user, immediately after the database write succeeds.

User Story

As a user who is currently logged in, I want to receive notifications instantly in my UI without having to refresh or poll, so that I am aware of critical events as they happen.

Acceptance Criteria

• Delivery hook: The dispatcher calls a delivery hook (interface-injected, not hard-wired) after successfully persisting a notification. The hook receives the full Notification struct.
• WS hub integration: The existing WebSocket hub is extended to accept a SendToUser(userID string, msg WSMessage) error method (or equivalent). If the user has no active connections, the call is a no-op — the notification is already persisted and will be retrieved via REST on next login.
• Message envelope: Notifications are delivered over WebSocket as a message of type notification.created, wrapping the full serialised Notification object. The envelope format must be consistent with the project's existing WebSocket message conventions.
• Multiple sessions: If a user has more than one active WebSocket connection (e.g. two browser tabs), the notification is delivered to all of them.
• No delivery guarantee: WebSocket delivery is best-effort. If the send fails (connection dropped mid-send), the error is logged but does not affect the persisted record. The UI is responsible for retrieving missed notifications via the REST API.
• Unit/integration tests: Tests verify the hub correctly routes a message to the right user connection(s) and that a missing connection results in a no-op with no error surfaced to the dispatcher.

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: The project already has a working WebSocket hub with per-user connection tracking. This PBI extends it, not replaces it.
• Constraint: The WS delivery path must not introduce any latency to the database write path. If the hub is unavailable or slow, it must not delay the dispatcher's return.

Dependencies

No response

Additional Notes

No response