Auth breadth: Microsoft and Apple, generic OIDC, magic links, passkeys and SMS codes, configured per tenant

Arnel, 14 September 2026: auth breadth is a gap worth closing. A site or app built on barako should offer the sign-in options people expect without custom code.

## What exists

- Username and password with MFA, API keys, device trust.
- Passwordless sign-in by a one-time email code (`OtpCode`).
- `BarakoCMS.ExternalAuth`: Google, GitHub, Facebook and LinkedIn, matched on a verified email, issuing the same tenant-scoped token as the built-in flows.

## Change

- **Microsoft and Apple** as ExternalAuth providers, with Apple's private relay emails handled as verified addresses that never match an existing account by guesswork.
- **Generic OpenID Connect** by issuer URL (#786), so Keycloak, Auth0, Entra ID tenants, Okta and Google Workspace work without a provider per vendor.
- **Magic links** beside the email code: a signed, single-use, short-lived link, opened with a confirmation step so mail scanners cannot sign anyone in.
- **Passkeys (WebAuthn)** as a sign-in method and as a second factor, building on device trust (docs/device-trust.md).
- **SMS code** through the existing SMS action's providers, rate limited per number and per IP.
- **Per tenant configuration.** Which methods a tenant offers, set by its admins, so one deployment can serve a club with Google sign-in and a school with Entra ID.
- **Client SDK helpers** (#182, #186): sign in, refresh and sign out for each method, so a consumer does not hand-roll the flows.

SAML stays out of this issue; it is its own decision.

## Done when

- A tenant enables Google and passkeys, another tenant enables only a generic OIDC issuer, and each sign-in page offers only its own methods, covered by tests.
- A magic link works once, expires, and a GET alone does not sign in.

## Where it lives

Modules: Microsoft, Apple and generic OIDC providers in `BarakoCMS.ExternalAuth`, and passkeys as their own module. Core: magic links and SMS codes beside the email one-time code the core already issues, and per-tenant sign-in method settings.

Start by reading the existing BarakoCMS.ExternalAuth providers, the core OtpCode flow, and docs/device-trust.md; the issue also references client SDK work in #182 and #186. Map how tenant sign-in settings would reach each sign-in page before implementing any one method. Done means the listed provider and passwordless flows work with per-tenant method visibility, and tests cover tenant isolation plus one-use, expiry, and non-signing-in GET magic links.

Written by the indexing model from the issue text.