parity(auth): SignOut() should clear local session even if remote call fails [from supabase-js]

[grdsdev]

SDK Parity: C# implementation needed

A change was made in supabase-js that needs to be implemented in this repository for SDK parity.

Reference Implementation (supabase-js)

• Commit: 314cca0
• PR: #2504
• Module: auth
• Type: bug-fix

What Changed

signOut() (for any scope other than 'others') now clears the local session and removes the PKCE code verifier even when the remote sign-out API call fails, instead of only doing so on success. A network/API error no longer leaves a stale local session that appears "signed in" client-side.

Code Reference

const removeCurrentSession = async () => {
  await this._removeSession()
  await removeItemAsync(this.storage, `${this.storageKey}-code-verifier`)
}
if (scope !== 'others') {
  await removeCurrentSession()
}

Confirmed in supabase-csharp: Gotrue/Client.cs:426-431 SignOut() awaits _api.SignOut(...) unguarded; if the remote call throws (network/API error), the exception propagates and UpdateSession(null)/NotifyAuthStateChange(SignedOut) never run, leaving a stale local session.

Implementation Guidance

Expected API Surface

SignOut() should clear the local session unconditionally for scopes other than "others", regardless of whether the remote API call succeeds or throws.

Acceptance Criteria

• Fix implemented matching supabase-js behavior
• Unit test: remote sign-out throwing a network error still results in local session being cleared
• No breaking changes to "others" scope behavior

Context

• supabase-js version: v3.0.0-next.29 / 2.110.6
• Parity tracking: This issue was auto-generated by SDK parity analysis
• Related parity issues: supabase-py (SDK-1326), supabase-kt (#1358)

---

Generated with Claude Code /sync-sdk-parity

[grdsdev]

Related parity issues:

• supabase-py: https://linear.app/supabase/issue/SDK-1326
• supabase-kt: parity(auth): signOut() should clear local session even if remote call fails [from supabase-js] supabase-community/supabase-kt#1358

[fresh55]

Same method as #258, so probably worth fixing together.