fix: override user info on GitHub sign-in to self-heal stale-emailed accounts

[mroderick]

Problem

PR #60 (merge e9ffa8f) resolved the duplicate-signup bug for new GitHub sign-ups by picking the primary + verified email from /user/emails. But it does nothing for users who already linked their GitHub account to the auth app before that shipped. Better Auth matches returning GitHub logins on the numeric GitHub account ID and reuses the user's stored email (e.g. the old public-profile address), so affected users stay bound to a duplicate planner account.

Fix

Set overrideUserInfoOnSignIn: true on the GitHub provider. Better Auth then overwrites the stored email with the freshly-resolved primary on every sign-in (including pre-linked accounts), so affected users self-heal to their primary email on their next login, with no manual data entry.

Verification

• Prettier + ESLint clean.
• test/unit/github-provider.test.js green (github-provider.js 100% stmts / 92.85% branch).

[mroderick]

Status update: existing duplicates are fixed in production; this PR is now preventative

The five existing affected users have been repaired directly in the planner's production database today — a merge of their duplicate members into their real accounts. Each merge:

• moved the duplicate's codebar auth_service onto the real member,
• removed the now-empty duplicate member row,
• cleaned up redundant subscriptions / workshop & event invitations.

Verified post-apply: no duplicate members remain and no orphaned references to the deleted rows.

A side note surfaced during the cleanup: the local codebar_dump was staler than production (a redundant member and one extra invitation were present only in production), which a first run of the script caught by rolling back on a unique index — the transaction's atomicity left production untouched, and the corrected script then applied cleanly.

Because the merges move each user's codebar / <stored-email> credential onto their real member, the planner's existing AuthService.find_by(provider, uid) now resolves to the correct account on their next sign-in. So the existing users are fixed irrespective of this PR.

That makes this change preventative rather than remedial:

• it stops overrideUserInfoOnSignIn-style drift by re-deriving the stored email from the provider on every sign-in, so a user's email can't silently fall out of step again;
• it protects any user who wasn't among today's five from the same class of bug going forward;
• it reduces the need for future manual merges.

Still worth shipping, but it is hardening — it is not what unblocks the current five.