Real-Time Notifications & Upload/Download Progress Reach QA (Unified WebSocket Layer)

This release promotes the consolidated real-time infrastructure from development into the QA environment. It rebuilds how the Mail and Vendor portals receive live updates — notifications, comment activity, and upload/download progress — on a single, more resilient connection layer, and ships a build fix that unblocked the QA deployment.

Real-time features had grown organically: each feature opened its own WebSocket connection with its own copy of reconnection, keep-alive, and authentication logic — roughly 700 lines of duplicated, drifting boilerplate across five files. Several connections still passed the login token in the URL, which is fragile and a security concern. In parallel, a QA deployment build was failing because the Vendor sidebar referenced a user property (entity_type) that no longer exists on the authenticated user object. Both needed to be addressed to get a stable real-time experience into QA.

For QA validation, this brings live, push-based updates into the Vendor and Mail portals: notification badges, comment activity, bulk-operation result toasts, and upload/download progress indicators now share one steady connection that survives brief network blips and reconnects automatically. The Vendor sidebar again shows the correct user role label, and the QA build is unblocked. There is no change to how end users log in — authentication now rides on the existing secure session cookie instead of being exposed in connection URLs.

This is a dev -> qa promotion (net +1541 / -1038 lines) bundling two feature branches:

• WebSocket consolidation (PR #807):
  • New shared @dsm/http-client/ws-utils.ts with resolveSocketBase() and a createReconnectingWebSocket factory; standardized constants (25s ping, 5s pong-timeout, up to 10 retries with exponential backoff + jitter).
  • New canonical WebSocket message types in @dsm/types/websocket.types.ts.
  • New NotificationsSocketProvider collapsing 3 separate notification connections into 1; notification, comments, and bulk-operation-toast hooks refactored onto it.
  • New useUploadStatusSocket and useDownloadProgressSocket hooks wired to /api/v1/ws/upload-status and /api/v1/ws/download-progress.
  • Switched all connections to cookie auth (dms_access); removed token-in-URL, including the vendor route /vendor/api/files/ws/{token} -> /vendor/api/files/ws.
  • Stability fix in useJobProgressSocket: reset job state only on job-id change, not on transient reconnects, so progress no longer resets to queued/0 on a blip.
• Build fix (PR #808): VendorSidebar.tsx now reads user?.tenant_type instead of the non-existent user?.entity_type, matching AdminSidebar.

Moderate. This is a broad refactor of shared real-time plumbing touching both portals, so regressions would most likely appear as missed live updates or noisy reconnect behavior rather than data loss. The change consolidates onto a single tested code path and removes duplicated logic, which lowers long-term risk. Mitigation: this lands in QA (not Production) precisely so the new connection lifecycle and cookie-based auth can be validated before promotion.

• Confirm the QA build deploys successfully and the Vendor sidebar shows the correct user role label.
• Verify live notifications, comment activity, and bulk-operation result toasts still appear in Mail without page refresh.
• Watch upload and download progress in both Vendor and Mail through to completion; confirm progress does not reset to 0 / queued mid-job.
• Drop and restore network briefly; confirm connections reconnect automatically and updates resume.
• Confirm no login token appears in WebSocket URLs (auth via session cookie) and unauthenticated sessions do not connect.