Fix false-positive Claude connection status

[hamzamerzic]

Summary

• validate the local Claude OAuth record instead of treating credential-file presence as connected
• accept a current access token with at least the existing 60-second refresh margin, or a nonempty refresh token whose optional refreshTokenExpiresAt is still in the future
• preserve compatibility with legacy Claude credential documents that omit refreshTokenExpiresAt
• report missing, malformed JSON, non-UTF-8, expired-access/unrefreshable, and explicitly expired-refresh records as disconnected with reconnect guidance
• update test fixtures that previously used an impossible empty credential document

Production symptom

A production Claude credential file retained OAuth metadata/scopes but had no access token, no refresh token, and an expiry of zero. The provider-status endpoint nevertheless returned configured/authenticated=true because the preflight checked only for file existence. A subsequent Claude turn failed authentication; switching that chat to Codex recovered it. No chat message content is included here.

This change is a local predicate only. It does not probe Anthropic or change token-refresh behavior.

Validation

82 focused backend tests passed after rebasing on current main, covering the auth predicate and status route, non-UTF-8 chat-preflight terminal cleanup, terminal completion, chat-writer activation, model registry, and chat agent settings. Cases include empty, malformed JSON, malformed encoding, current-access, legacy refreshable, future-expiring refreshable, expired-access/unrefreshable, and explicitly expired refresh-token credentials.

Residual risk

A revoked but unexpired (or legacy expiry-less) refresh token continues to count as configured until a refresh is attempted. Detecting revocation here would require a remote token probe, which is intentionally outside this passive status path.