fix(auth): take the member email from the UserInfo endpoint

[mroderick]

Sign-in now resolves the member email and name from the OIDC UserInfo response instead of the id_token, so it keeps working with better-auth 1.7's sparse id_tokens and never keys a member on sub.

• Email comes from userinfo only; a blank one fails the callback with :missing_email, so no member is created from a non-email id. The id_token email claim is not consulted.
• A failed userinfo request fails with :userinfo_failed, so a degraded auth app is distinguishable from a member without an email. Common Net::HTTP and OpenSSL transport errors are rescued into that path, and a non-object userinfo body counts as a request failure.
• Name falls back from userinfo to the id_token name, then to the email address.
• The id_token stays the source of sub and github_id in extra.raw_info; the controller's returning-member resolution is unchanged.

This continues the :missing_email guard from #2986, which is already on master: the guard stays as the integrity floor, and the email source moves to userinfo. Cleaning up members already keyed on better-auth user ids remains follow-up work. The auth app needs no claims code for this, so codebar/auth#83 can close.

This is the same change as #2989, which merged into its stacked base branch instead of master; the change is unchanged and rebased onto master.

Review notes

Focus on the failure semantics and the email precedence. Userinfo is the only email source, even when the id_token carries one: a blank email there fails :missing_email, a failed request fails :userinfo_failed. There is no fallback to the id_token email.

Deliberately not done: a sub-match guard between the id_token and the userinfo response (better-auth re-pins sub), checking email_verified (the auth app's verification policy is trusted as before), and shortening the userinfo timeout or capping concurrent callbacks under a degraded provider.

Related: #2986, codebar/auth#83