Browser-validate the account-claim flow end-to-end

まずこのブランチ、またはマージ後の main から開発サーバーを実行し、その後、issue に記載された 2 つの GitHub サインインシナリオに従います。PR #46 にある既存のアカウント要求画面を使用し、複数候補のケースで必要であれば people/*.toml レコードを 2 つ用意します。単一候補の詳細と matchedVia の値が正しく、複数候補のカードを 1 つ選択するとその人物だけが要求されれば完了です。

Context

The account-claim plan (PR #46) covers all paths via unit + integration tests against the in-process Fastify instance. Two validation criteria depend on the running browser experience and were not flipped at merge:

• OAuth callback with candidates → claim screen renders the candidate(s) with the right info
• Multi-candidate picker works; selecting one claims it; others remain unclaimed

The implementation is complete; this is purely a manual / playwright verification gap. The parent-repo dev server was busy during the implementation window so I couldn't drive a real GitHub OAuth flow through the new screens without disrupting other agents.

Verification

Run dev in this branch (or a checked-out post-merge main) and:

1. Sign in via GitHub against a laddr-era email that matches a single legacy Person. Confirm the claim screen renders one card with matchedVia: email, fullName, slug, and member count.
2. Repeat against a GH identity whose gh.login and email both match different legacy Persons (multi-candidate). Confirm the picker shows both cards; select one; confirm only that Person gets the GH identity and the other stays unclaimed.

Notes: a quick way to seed the multi-candidate path locally is to add two people/*.toml records with distinct slugs and email-match one to your real primary GH email, and have the GH login field equal the other slug.