Normalize Salesforce connection errors to appropriate HTTP status codes

[paustint]

Improve error handling for Salesforce connection issues by normalizing specific errors to their corresponding HTTP status codes. This change prevents misleading 500 errors from being sent to clients for authentication failures and ensures that users are prompted to reconnect when necessary.

[Copilot]

Pull request overview

This PR improves API error handling for known Salesforce connection/auth failures by mapping them to deterministic 4xx HTTP status codes (instead of sometimes passing through Salesforce’s upstream 5xx statuses), reducing misleading “server error” responses and avoiding false 5xx alerting.

Changes:

• Detects known Salesforce connection/auth error messages and normalizes the HTTP status to 401 (auth/connection) or 403 (“REST API not enabled”).
• Reuses the same detection for (a) org invalidation side-effects and (b) deferred-mode error body enrichment, avoiding duplicated condition checks.
• Adds Vitest coverage to ensure both UserFacingError and generic/unwrapped errors normalize to 4xx as intended.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
apps/api/src/app/utils/response.handlers.ts	Adds message-based detection for known Salesforce connection errors and normalizes response status to 401/403 across both typed and generic error paths.
apps/api/src/app/utils/tests/response.handlers.spec.ts	Adds tests validating normalization behavior and that org invalidation side-effects still occur for expired-token scenarios.