Managed auth provider adapters (Clerk, Supabase, Auth0)

The auth foundation shaped `auth.Resolver` so a managed provider can satisfy it, and named Clerk, Supabase and Auth0 as the conforming implementations it was designed against — but none was built, and the design deferred them explicitly (`docs/superpowers/specs/2026-08-31-auth-foundation-provider-abstraction-design.md`, *Deferred*). Adopting one is more than writing a Resolver: it needs just-in-time user provisioning on first sign-in, a decision about whether the local register/login endpoints stay or are disabled, and somewhere for provider configuration to live.

Distinct from #27, which is social OAuth sign-in as another Resolver alongside the local flow; this is replacing the identity system with a hosted one. Whether all three ship or one lands first as a proof is open.

Came out of reviewing the deferred sections of the existing specs.

Start with docs/superpowers/specs/2026-08-31-auth-foundation-provider-abstraction-design.md, especially the Deferred section, and inspect auth.Resolver. Compare the scope with issue #27, then clarify whether one provider or all three is intended, how first-sign-in provisioning and provider configuration should work, and whether local endpoints remain; done requires those decisions and a selected implementation scope.

Written by the indexing model from the issue text.