Expose provider management and server-owned TOTP enrollment over REST

Problem

Frontend account settings outside wp-admin cannot manage Two Factor without duplicating security ownership. The current REST surface is provider-fragmented and incomplete:

• TOTP exposes POST/DELETE, but POST requires the client to generate and submit the secret.
• Backup codes expose generation only.
• Email has no REST management route.
• Generic provider status, configured/enabled distinctions, primary selection, recovery-code count, and recent-revalidation state are available only through PHP/profile UI.

This blocks a layer-pure frontend settings implementation in Extra-Chill/extrachill-community#225.

Current source evidence

At 70485b0:

• TOTP routes: providers/class-two-factor-totp.php:94-141; setup accepts caller-supplied key at 226-265; server-side key/URI generation exists only in profile rendering at 334-449.
• Backup-code route: providers/class-two-factor-backup-codes.php:74-97; generation callback at 288-339.
• Email provider registers no REST route.
• Provider state and primary resolution exist in class-two-factor-core.php:629-830.
• Generic enable/disable PHP methods exist at class-two-factor-core.php:2326-2393 and intentionally require callers to enforce permission.
• Existing REST permission helper enforces edit_user plus recent-2FA revalidation at class-two-factor-core.php:1527-1553.

Proposed narrow upstream surface

1. Authenticated provider-settings GET:

   • Stable provider key and label.
   • Supported, configured, enabled, and primary state.
   • Remaining recovery-code count where applicable.
   • Structured recent-revalidation requirement/target.
   • Never return an existing TOTP secret.

2. Permission-checked provider settings mutation:

   • Enable/disable generic providers, including Email and Recovery Codes.
   • Select primary only among configured and enabled providers.
   • Reuse existing capability checks, recent-2FA gate, and session invalidation semantics.

3. Server-owned TOTP begin-enrollment:

   • Generate a new secret server-side.
   • Return the secret and otpauth:// URI once for setup display.
   • Confirm through the existing code validation/storage behavior.
   • Expire or replace abandoned pending enrollment state.

Security constraints

• Do not expose provider user meta directly through generic user REST responses.
• Do not require presentation clients to generate MFA secrets.
• Preserve recent-2FA revalidation before sensitive changes.
• Keep setup secrets one-time and prevent retrieval after confirmation.
• Reuse existing provider/core methods rather than creating parallel MFA state.

I can prepare a focused PR if this route shape is acceptable.

Start with the TOTP and backup-code provider files, then read provider state and permission handling in class-two-factor-core.php, especially lines 629-830 and 1527-1553. Trace the existing profile enrollment and generic enable/disable paths before defining the REST behavior. Done means the proposed provider status, mutation, and server-owned enrollment flows preserve revalidation, one-time secrets, validation, storage, and session invalidation semantics.