Complete a provider ceremony (redirect callback)

Completes an attempt from a provider that redirects with a query string (Google, GitHub).

The route serves two ceremonies, and which one runs is decided from server-side state, never from the request. A sign-in sets both browser-session cookies and, by default, redirects to the existing /app launch entry. The browser resolves the exact active Workspace ID to its readable path before opening Projects. Accounts without a Workspace continue to Workspace creation; validated explicit continuations retain their destination. It first resolves an exact (provider, provider_subject) identity. If none exists and the provider supplies a verified email matching an existing normalized account address, the callback atomically attaches the new identity and signs in that existing account; an absent or unverified email cannot do so. An identity link started from POST /api/v1/me/identities issues no session and rewrites no cookie — the caller is already signed in — and redirects to the identity settings surface instead. A ceremony is claimed by a single conditional update with its purpose in the predicate, so a link can never be redeemed as a sign-in and a sign-in can never be redeemed as an explicit account-settings link ceremony.

On failure the response still redirects, to the web application's login page with an opaque error indicator, so the content-free authentication boundary is preserved even in a browser navigation.