fix: only terminate the session on 400 invalid_grant

[germ-mark]

Follow-on to #53, which narrowed session termination on token refresh but still defaulted to terminate: only OAuth.Errors.oauthError was inspected, so anything else fell through to return nil and signed the user out.

Two cases that don't confirm the refresh token is dead still terminated the session:

• Undecodable error bodies — HTML or empty 5xx from a proxy/CDN throws HTTPResponseError.unsuccessful, not oauthError. Probably the most common transient failure in practice.
• 400 invalid_request — processGenericAccessToken remaps this before the oauthError case; per RFC 6749 it means a malformed request, not a revoked grant.

Inverts the catch into an allowlist: only 400 invalid_grant returns nil, everything else propagates. Preserving is now the default for unrecognized errors.

Stacked on #51 — merge after it lands. Based on feat/token-revocation with main merged in, so CI runs the true post-stack state; the error assertions rely on GermConvenience 0.3.0, which that branch already pins.

Tests: three new cases in RefreshErrorTests (HTML 503, empty-body 502, 400 invalid_request), added in a separate commit that fails against the pre-fix code. Full suite green.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: ba721c5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@germ-network/oauth4swift	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[germ-mark]

Extended to cover a third case from a parallel review: TokenRefreshOptions.validate documents a thrown error as "unable to resolve the validity - e.g. if an online check is required and the client is currently offline", but the refresh path caught it and nilled the session just the same — so an offline client (or a transient failure in atproto sub-verification) lost its session. Only an explicit false terminates now; a throw propagates.

That also removes the second do/catch entirely, since a failure fetching authServerMetadata should propagate for the same reason.

[germ-mark]

Self-review follow-up: a validator shared across both flows may throw tokenInvalid (per TokenAuthorizeOptions's convention) rather than return false — that throw now terminates the session like false does, instead of being preserved-and-retried. Also added the missing happy-path test: a valid refresh returns the new access token and updates the stored token state. 19 tests total.