Mail: More resilient real-time connection and request timeout safeguard (QA)

The Mail application's real-time connection now automatically recovers after routine backend pauses instead of going silent, and slow requests are now bounded by a timeout so the interface no longer hangs indefinitely. This batch promotes those reliability fixes to the QA environment for verification.

The Mail live-update connection (WebSocket) was treating the backend's normal disconnect signal as a permanent shutdown. The backend, however, issues that same signal during routine idle timeouts and worker recycling — situations the connection should recover from. As a result, real-time updates could quietly stop after periods of inactivity. Separately, network requests had no upper time limit, so a stalled backend response could leave the UI waiting forever.

Users on the Mail app should see live updates continue working after the page sits idle, rather than needing a manual refresh to reconnect. Requests that stall will now fail within 60 seconds instead of hanging open, giving clearer, faster feedback when something goes wrong. These are stability improvements with no change to existing features or workflows.

Grounded in the diff (2 files, +34/-9):

• packages/http-client/src/ws-utils.ts: Removed close codes 1000 (Normal) and 1001 (Going Away) from the no-reconnect skip set, so the client now reconnects after backend idle timeouts and worker recycling. User-initiated closes remain suppressed via the existing disposed flag.
• Added handling for server-initiated keep-alive pings: replies pong to a plain-text ping and {"type":"pong"} to a JSON {"type":"ping"}, mirroring the incoming format.
• apps/mail/src/http/api.ts: Added a 60s axios timeout (API_REQUEST_TIMEOUT_MS) to the shared API client, matching the backend request-timeout middleware.
• Note: the PR description references a mail middleware forwarded-host fix and temporary debug headers, but those changes are not present in this PR's diff (only the two files above changed). Folded in via merged PR #962 (ws reconnect) and references issue #141.

Low risk. The reconnect change widens the set of conditions that trigger automatic reconnection; the main concern is reconnect loops if the backend repeatedly drops connections, but exponential backoff and the disposed guard mitigate this. The 60s request timeout is conservative and aligned with the backend; very long-running requests (if any exist) could now be cut off and should be confirmed during QA.

• Leave the Mail app idle past the backend idle timeout (~120s) and confirm live updates resume automatically without a manual refresh.
• Verify the connection still closes cleanly (no reconnect attempts) when navigating away or explicitly closing the app.
• Confirm keep-alive pings are answered: connection stays alive during extended idle sessions and does not drop.
• Trigger or simulate a slow/stalled request and confirm it fails at ~60s rather than hanging indefinitely.
• Smoke-test normal Mail flows (inbox load, opening mail) to ensure the timeout does not prematurely abort legitimate requests.