Hosting CLI: distinguish permanent and retryable token validation failures #7537

Authentication validation currently maps every API status other than 401/403 to TokenValidationError("server error"), discarding the status and API explanation from the user-facing error. This behavior predates #7434. Its shared retry guidance makes the limitation visible: a permanent malformed-request response can receive advice to try again later.

Found while reviewing #7434 (comment). Collected separately to keep the expired-token recovery fix scoped.

Local reproduction (no live cloud account or network request): configure the existing tests.units.reflex_cli.sdk.fake_client() so client.api.auth.me.side_effect = api_error(400, "Malformed authentication request"), then call hosting._validate("fictional-token", client.api). The resulting exception is TokenValidationError("server error"), with an underlying HTTP 400 cause; _token_validation_failure_message suggests retrying later.

This demonstrates a possible response-handling case, not evidence that the live authentication endpoint currently returns HTTP 400 for ordinary CLI requests.

Follow-up scope:

• Preserve useful API status/detail when wrapping validation errors.
• Distinguish permanent request failures from failures worth retrying; account for retryable client responses such as HTTP 429 rather than treating every 4xx alike.
• Give actionable diagnostics for permanent failures and reserve retry advice for appropriate cases.
• Keep 401/403 credential recovery, request-ID reporting, saved-credential preservation, and JSON stdout behavior intact.
• Add regression coverage for a permanent 400, 429, 5xx, connection failures, and timeouts through the authentication callers.