feat(gotrue): surface the sign-out reason on the signedOut event

[spydon]

What

Adds AuthState.exception, populated when the user is signed out involuntarily because the session could not be recovered (an invalid or expired refresh token). It is null for an explicit signOut() and for every event other than signedOut.

Stacked on top of #1450. Base branch is fix/recover-session-duplicate-auth-error; review/merge that one first. The diff here is only the follow-up commit.

Why

Follow-up to the discussion on #1450. That PR stops recoverSession from double-reporting an expected sign-out as an uncaught stream error. The remaining concern was that a pure onAuthStateChange listener then sees signedOut without knowing why the user was signed out, which removes the ability to handle it differently or notify the user.

This restores that capability through the event itself, rather than through an error that only reaches listeners with an onError handler:

supabase.auth.onAuthStateChange.listen((state) {
  if (state.event == AuthChangeEvent.signedOut && state.exception != null) {
    // involuntary sign out (e.g. expired session) -> show a message
  }
});

How

• AuthState gains a nullable exception field.
• notifyAllSubscribers accepts an optional exception and threads it onto the AuthState.
• _executeRefresh passes the causing AuthException when it signs the user out on a non-retryable refresh failure.

The exception is intentionally not propagated across tabs via the broadcast channel, so it is always null when fromBroadcast is true.

Tests

• signedOut event carries the exception on an invalid refresh token.
• signedOut event has no exception on an explicit signOut.

[Vinzent03]

Adding an exception field to the class feels a bit strange, if we simultaneously use errors on the stream itself. But I cannot come up with a better solution right now. I thought about an enum at first as well like you did here: #1450 (comment), but that is probably hard to properly maintain and this solution is more general.
However, I think you've missed the sign out reasons in the recover method, right? They only have a human message and no special code to handle. Might be interesting to create a code that we use across similar issues in the recover method?