fix(supabase): avoid dropping realtime auth to manual mode on client init

[hmnd]

🔍 Description

When using a custom callback for accessToken on SupabaseClient, realtime gets stuck on the access token initially set during init, rather than refreshing from the callback as expected.

What changed?

I've replaced the previous approach of manually requesting the accesstoken inside SupabaseClient's constructor with an empty call to realtime.setAuth(). This way realtime retrieves and sets the access token on its own, without dropping to manual mode.

Why was this change needed?

I ran into this issue with my custom minted jwts. I found #1304, in which the fix was to manually call supabase.realtime.setAuth() with no args to re-enable callback mode for access tokens.

I also couldn't find any documentation advising users of custom tokens that they must always call do this after client init, making for poor UX and confusing bugs.

Closes #1304

🔄 Breaking changes

Technically not a breaking change but, with this change, we do lose the Failed to set initial Realtime auth token error message if the accessToken function throws, because realtime's setAuth has its own error handling.

• This PR contains no breaking changes

📋 Checklist

• I have read the Contributing Guidelines
• My PR title follows the conventional commit format: <type>(<scope>): <description>
• I have run pnpm nx format to ensure consistent code formatting
• I have added tests for new functionality (if applicable)
• I have updated documentation (if applicable)

📝 Additional notes

#1304 really shouldn't have been closed and that is what frustrates me about stale bots. I would kindly suggest reconsidering the repo's usage of stale bot, or altering its config to eg. re-open issues if commented on after auto-close.