Apple: registration and login with minted client secret and form_post

[ParallelEntrepreneur]

Part of #1.

Blocked by: #3 (Spike: Apple client secret minting, form_post callback and first-authorization name); #15 (Google: registration and login via openidconnect); Cratefield/harness#46 (form bodies)

Problem. Apple reuses the OIDC machinery from the Google issue but with the three differences the spike resolved: a minted client secret, a cross-site form_post callback, and a name that arrives once.

Proposed approach.

• Provider descriptor for Apple on the auth-oidc module with the spike's decisions applied: client secret from apple::mint_client_secret() with the in-memory cache, state transported as decided, response_mode=form_post, scopes name email.
• POST /apple/callback accepting form-encoded bodies (harness prerequisite), verifying the ID token against Apple's JWKS, capturing the user JSON when present and storing name_at_link.
• Email may be a private relay address; email_verified from Apple is trusted for linking only when the address is not a relay, per the account-linking rules.
• Apple requires the "Sign in with Apple" button assets and the Services ID's return URLs to be registered exactly; document that in the runbook.

Acceptance criteria

• Callback tested with a recorded form_post body including a user field, and one without
• Client secret minting tested: claims, expiry under six months, kid header, cache hit
• Relay address never links to an existing account; tested through the linking rules
• Manual run against a real staging Services ID

[ParallelEntrepreneur]

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

Done

• Callback tested with a recorded form_post body including a user field, and one without — tests/apple.rs, 13 tests
• Client secret minting tested: claims, expiry under six months, kid header, cache hit
• Relay address never links to an existing account; tested through the linking rules
• Manual run against a real staging Services ID

What remains, and why it cannot be faked

No Apple Developer account, Services ID or .p8 exists on this machine, so nothing here has talked to Apple. The fake mints real ES256 and RS256, serves Apple's own discovery shape, sends email_verified as the string Apple sends, and posts a real form body — which covers the verification path and not Apple's own behaviour. Specifically untested:

1. that Apple accepts a client secret minted exactly this way (claims, one-hour expiry, kid header);
2. that the registered return URL matches byte for byte — Apple compares exactly, and the domain must be verified first;
3. the real shape of the user field on a genuine first authorization.

For whoever has the account

The runbook is in the crate README: create a Services ID, register <AUTH_OIDC_REDIRECT_BASE>/v1/auth-oidc/apple/callback on it, create a Sign in with Apple key and set the four settings. Then start at /v1/auth-oidc/apple/start and confirm a first authorization keeps the name and a second signs in without one.

Worth knowing before you try: the review caught that accept-string-booleans was off, which would have refused every real sign-in while every test passed. If something still fails against live Apple, suspect a claim's type before suspecting the key.