Meta: login via OAuth2 and Graph profile

[ParallelEntrepreneur]

Part of #1.

Blocked by: #4 (Spike: Meta as OAuth2 plus Graph profile, and the data deletion callback); #8 (Sessions: issuing, validation, sliding expiry, revocation and logout); Account linking: one user, many identities, and the email-match rules

Problem. Facebook Login is plain OAuth2 with a profile call, implemented on the oauth2 crate as the spike decided.

Proposed approach.

• GET /meta/start: authorization URL with email public_profile, state in the signed cookie, redirect.
• GET /meta/callback: state check, code exchange through the HttpClient port, then GET /me?fields=id,name,email; email may be missing and is treated as unverified when present unless Meta documents otherwise.
• Identity (provider = meta, subject = Graph id, email?, name) handed to the linking rules; session issued.
• App-scoped user ids are per app; the subject is stored as returned and documented as not portable across Meta apps.

Acceptance criteria

• Start and callback tested with a fake HttpClient for the token and profile calls, with and without an email
• State mismatch and a token exchange error both fail cleanly
• Manual run with a Meta test app in development mode

[ParallelEntrepreneur]

The code is merged (#39, e25fd81). This stays open for the one acceptance criterion nobody here can meet.

Done

• Start and callback tested with a fake HttpClient for the token and profile calls, with and without an email
• State mismatch and a token exchange error both fail cleanly — and a profile-call failure, and an expired flow, and a missing cookie
• Manual run with a Meta test app in development mode

Beyond what was asked

• The address Meta reports is normalised before the linking rules see it. Found by review: un-normalised, Ada@Example.com missed an existing ada@example.com and quietly made a second account whose address no normalised lookup would ever find again.
• email_verified is hard-coded false, so a Meta sign-in can never auto-link onto an existing account. Tested from both sides.
• The step that turns a verified identity into a session moved to auth-core::federated, shared with Google and Apple.

What remains, and why it cannot be faked

No Meta app, app secret or test user exists on this machine, so nothing has talked to Meta. The fake serves a real token-endpoint shape and a real Graph profile shape, and the real oauth2 client makes the request — which covers this module's logic and not Meta's behaviour. Specifically untested:

1. that the authorization dialog accepts these parameters as sent;
2. that the registered redirect URI matches (Meta compares exactly);
3. the real shape of a Graph error;
4. whether v21.0 is a version Meta still serves — this is the one most likely to be wrong, which is why it is AUTH_META_GRAPH_VERSION rather than a constant.

For whoever has the account

The runbook is in the crate README. Create the app, set the four settings, and start at /v1/auth-meta/start.

Worth knowing before you try: the Apple work had the same shape, and the thing that would have broken every real sign-in there was a claim type the fake got politely right and the provider does not. If something fails against live Meta, suspect the Graph version and the redirect URI before suspecting the code.