feat(chat): alert on new messages with sound and browser notifications

[bamdadd]

What

Incoming WhatsApp messages now proactively alert the assigned agent with a sound and — when the tab is backgrounded — a native browser notification, instead of only silently incrementing the sidebar unread badge.

Why

Today an incoming message only shows up as a small unread count in the contact list, so an agent has to actively watch the screen to notice a new chat. Three separate gaps caused this:

1. Assignment gate too narrow — the toast + sound only fired when the chat was assigned to the current user. Unassigned chats bumped the badge with no alert at all.
2. Autoplay-blocked sound — the notification audio was created and played without any prior user gesture, so the browser autoplay policy rejected the very first play() and the sound was dropped.
3. No out-of-tab signal — alerts were in-app toasts only, invisible when the browser tab was backgrounded or minimized.

How

• Broaden the alert rule: an incoming message now alerts when the chat is assigned to you or unassigned; chats owned by another agent stay quiet to avoid cross-agent noise. The decision is extracted into a pure shouldNotifyIncoming() helper (frontend/src/services/notifications.ts).
• Prime the audio: the sound element is unlocked on the first pointerdown/keydown (played muted once, then reset) so later alerts play reliably. Browser notification permission is requested in the same gesture.
• Native notifications: when the tab is not visible/focused and permission is granted, fire a window.Notification (click focuses the window and routes to the chat); otherwise fall back to the existing in-app toast.

Tests

• New shouldNotifyIncoming unit tests cover assigned / unassigned / other-agent / outgoing / already-viewing / alerts-disabled / default-on cases.
• Adds a minimal Vitest setup (vitest.config.ts + test:unit script); the repo previously had only Playwright e2e. npm run test:unit → 7 passing.
• npm run typecheck and eslint clean on changed files.

Notes

• Browser notifications require the user to grant permission (prompted on first interaction). If previously denied, it must be re-enabled in the browser's site settings.
• No backend changes.