Fix social account disconnects: refresh tokens per platform's refresh model

[paulocastellano]

Fixes #126.

Problem

Social accounts were being marked disconnected far more often than they should be, forcing frequent reconnects. The root cause was proactive token refresh that ignored how each platform actually refreshes its tokens — and it broke in two opposite ways.

Rotating refresh-token platforms (X, LinkedIn, TikTok, Pinterest, YouTube, Bluesky). Their refresh tokens are single-use / rotating — every refresh returns a new pair and invalidates the old one; sending an already-rotated token can invalidate the whole token family and force a reconnect. The old code rotated far too often:

• RefreshExpiringTokens refreshed anything expiring within 2h and ran hourly, but X access tokens live exactly 2h — so every X account was rotated every hour while still valid.
• RefreshSocialToken called refreshToken() directly, bypassing verify()'s access-token-first guard.
• A first 4xx disconnected the account without checking whether a concurrent refresh had already persisted a working token.
• Every publisher/analytics service (23 sites) also refreshed on "expiring soon", rotating still-valid tokens.

Extension-token platforms (Instagram, Threads). These have no separate refresh token — they refresh by extending the access token itself, and per Meta's docs the token must be unexpired to refresh ("at least 24 hours old but has not expired"; once expired it "can no longer be refreshed"). So they must be refreshed while still valid — the opposite of the rotating platforms.

Fix

Gate proactive refresh on the platform's refresh model:

• Platform::extendsAccessTokenOnRefresh() — true only for Instagram/Threads.
• SocialAccount::needsProactiveTokenRefresh() — refresh when expired for rotating platforms, OR when expiring-soon for extension platforms.
• Proactive job (RefreshSocialToken): route rotating platforms through verify() (access-token-first) so they only rotate once actually expired; extend (refreshToken()) extension platforms while still valid.
• Per-model refresh window (RefreshExpiringTokens, cron every 15 min): rotating platforms use a tight 30-minute window (verify-first means being in-window just re-verifies, never rotates a still-valid token); extension platforms (Instagram/Threads) get a 24-hour lead, because they can't be refreshed once expired and the job runs on the backlog-prone default queue — a short window risked a permanent lapse under queue delay.
• Never persist a null token expiry for Instagram/Threads. A null token_expires_at silently drops an account from every refresh path (the cron's whereNotNull and the is_token_expired/is_token_expiring_soon checks), so the token lapses. Threads no longer completes a connect with only the ~1h short-lived token when the long-lived exchange fails (it fails the connect so the user retries), and a refresh that omits expires_in now defaults to 60 days (Platform::LONG_LIVED_TOKEN_TTL_SECONDS, centralized) for both Instagram and Threads.
• A Meta rate-limit no longer disconnects a valid Instagram/Threads token. Meta returns rate-limit (code 4/17) and transient (code 1/2) errors as HTTP 4xx with type: OAuthException, and TokenRefreshClient classified every non-5xx/429 failure as a dead token → a throttled proactive refresh disconnected still-valid tokens (and the wider refresh cadence raised the odds). Classification now keys on error code 190 — the signal the publish exceptions already use — via a shared Meta\GraphError helper: only a genuine 190 disconnects; every other Meta 4xx is transient (PlatformUnavailable) and retried next cycle. The same over-broad type-based check in verifyInstagram/verifyFacebook/verifyThreads was replaced with the helper so verify and refresh agree.
• Lost-rotation race: verify() now reloads and uses a concurrently-refreshed token before marking an account expired.
• All 23 publisher/analytics pre-checks use needsProactiveTokenRefresh().

Platform audit

All 13 platforms were checked against the code and the providers' docs:

• Extension model — must refresh while valid: Instagram, Threads (the only two; both handled).
• Rotating / separate refresh_token — safe (refresh works after the access token expires): X, LinkedIn, LinkedIn Page, TikTok, YouTube, Pinterest, Bluesky.
• Never expire — excluded from the proactive window (whereNotNull): Facebook, Instagram-via-Facebook, Mastodon, Telegram, Discord.

Cold review of existing-token / deploy safety

An adversarial pass over the existing social_accounts data confirmed no currently-connected row is broken, disconnected, or unnecessarily rotated versus main: every divergence either reduces rotation/false-disconnects for rotating platforms, widens the harmless extend window for Instagram/Threads, or is a no-op for the null-expiry / never-expire rows. The only real risk it surfaced — the Meta rate-limit false-disconnect above — is fixed in this PR.

Tests

• Proactive job routes rotating platforms through verify() (still-valid X token is not rotated) and extends still-valid Instagram and Threads tokens.
• Per-model window: extension-model accounts are dispatched well ahead of expiry while rotating accounts with the same expiry are not.
• Threads connect fails (persists nothing) when the long-lived exchange fails, and records a 60-day expiry when expires_in is omitted; Instagram/Threads refresh do the same.
• Meta rate-limit handling: a 400 OAuthException code 4/17 on refresh raises PlatformUnavailable (not a disconnect), code 190 raises TokenExpired; the proactive job leaves a rate-limited Instagram account Connected; verifyInstagram returns false (no disconnect) on a rate-limit; Meta\GraphError unit-tested for 190 vs 4/17/2/none.
• ConnectionVerifier regression test: a 4xx refresh with a concurrently-rotated token does not disconnect the account.
• needsProactiveTokenRefresh() model test covers the rotating-vs-extension branching.
• No-rotation tests for the X and LinkedIn publishers.
• Full suite green: 2370 passing, 2 skipped, 0 failures.