v1.6.5

pollen v1.6.5

A small correctness patch closing an RFC 6749 §6 compliance
gap that v1.6.4 amplified. One fix, no new surface, no
behavior changes outside the bug it addresses.

The OAuth refresh path silently dropped the existing
refresh_token whenever an IdP omitted it from the refresh
response. Per RFC 6749 §6, omitting refresh_token in the
response means "keep using the one you sent us" — and a
number of mainstream IdPs do exactly that. Google OAuth
documents the behavior explicitly: "the refresh token might
not be returned with every access token". Microsoft Entra,
Auth0, and Okta also support non-rotating configurations.

Pre-v1.6.5 pollen's Refresh function returned whatever the
server gave back, including an empty refresh_token, and let
the caller (the auto-refresh-on-send path from v1.6.0) store
the empty value. v1.6.4's disk persistence then wrote that
empty value to ~/.config/pollen/oauth_tokens.json, so every
subsequent session lost the ability to refresh against the
same IdP — exactly the value proposition that v1.6.4 was
supposed to deliver, defeated.

The fix lives in oauth.Refresh: when postForm returns a
Token whose RefreshToken is empty, Refresh fills it from
the caller-supplied cfg.RefreshToken. This matches what
golang.org/x/oauth2 does and aligns with the RFC. The
rotation path (server returns a new refresh_token) is
unaffected — the new token still replaces the old.

Fixed:

• oauth.Refresh now preserves the input refresh_token when
  the IdP omits it from the response. With v1.6.4's disk
  persistence, this means refresh capability survives across
  sessions for non-rotating IdPs like Google OAuth

Notes:

• v1.x SemVer-frozen surface unchanged. No settings, key
  bindings, or on-disk file formats changed
• Existing on-disk entries that already lost their
  refresh_token from earlier (v1.6.4) sessions cannot be
  recovered automatically — re-fetch via g (CC) or
  re-authorize via browser (AC) once, and future refreshes
  then persist correctly
• The rotation path (server returns a fresh refresh_token)
  is untouched and still propagates + persists the new token

See CHANGELOG.md for the full list.