[Destynova2]

What

A refresh that fails before the TCP/TLS connection is established never reaches the issuer, so the stored refresh token is neither spent nor rotated. Yet refresh_token left the .refresh.pending uncertainty marker in place on any error returned by do_refresh:

self.token_store.begin_refresh(&existing_token)?;      // writes <provider>.refresh.pending
let response = self.do_refresh(&existing_token).await?; // transport error propagated as-is

On the next tick, begin_oauth_refresh finds the marker's fingerprint equal to the current refresh token and refuses:

Previous OAuth refresh outcome is unknown; replace credentials or authenticate again

So a single transient connect failure (brief outage, DNS hiccup, daemon waking from sleep) wedged every subsequent refresh permanently, until a manual grob connect --force-reauth — even though the refresh token was still valid. The existing non-success handling only clears the marker on an explicit 400/401/403, which the connection-never-opened case never reaches.

Change

Clear the marker when do_refresh fails with a reqwest connection-phase error (reqwest::Error::is_connect()): the request provably never left the client, so the next tick can safely retry the still-valid token.

Timeouts and post-send/read failures intentionally keep the marker — there the outcome is genuinely unknown, and re-auth is the correct conservative answer.

Test

connect_failure_does_not_wedge_future_refreshes points a store-backed client at http://127.0.0.1:1 (no listener → connect refused) and asserts that two consecutive refreshes both surface the connect error, and neither returns the "outcome is unknown" wedge. Before the fix, the second attempt wedged.

Fixes #663