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

## Context

The account-claim plan ([PR #46](https://github.com/CodeForPhilly/codeforphilly-ng/pull/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.

Start by running the dev server from this branch or post-merge main, then follow the two GitHub sign-in scenarios described in the issue. Use the existing account-claim screens from PR #46 and seed two people/*.toml records if needed for the multi-candidate case. Done means the single-candidate details and matchedVia value are correct, and selecting one multi-candidate card claims only that person.

由索引模型根据 Issue 内容生成。