Replace manual Cloudflare API token setup with secure connected-account flow

Summary

Perform currently supports Cloudflare cache sync by asking the site owner to paste a Zone ID and API token into plugin settings. Replace the default setup path with a "Connect Cloudflare" style connected-account flow using Cloudflare's supported OAuth/API authorization model, while keeping manual API token entry as an advanced fallback for sites where connect mode cannot be used.

Current behavior

The current implementation stores Cloudflare connection settings in Perform settings and uses the token server-side when purging cache:

• src/Includes/Helpers.php exposes enable_cloudflare_cache_sync, cloudflare_zone_id, and cloudflare_api_token settings.
• src/Modules/Cache/PageCache.php sends purge requests to Cloudflare's zone purge endpoint with a bearer token.
• src/Admin/Settings/ClientPayload.php masks the token before settings are sent to the admin UI.

That is workable, but the default UX still asks non-technical users to create, scope, copy, and store a long-lived credential manually.

Proposed direction

Make connected account setup the primary path:

• Add a primary "Connect Cloudflare" flow that uses Cloudflare OAuth / connected application support if feasible for a distributed WordPress plugin.
• Confirm the right OAuth client model before implementation, including whether Perform needs a public OAuth client, a hosted callback, PKCE, or another Cloudflare-supported authorization approach.
• Request only the minimum scope needed for cache purge and zone selection.
• Add connection status, zone selection, disconnect/reconnect, token health, and clear failure states.
• Keep manual API token setup as an "Advanced" or "Manual setup" fallback, not as the default onboarding path.
• Preserve existing cloudflare_api_token users through a backward-compatible migration path.

Security and compatibility requirements

• Never expose OAuth secrets, access tokens, refresh tokens, or manual API tokens in JavaScript payloads, logs, notices, REST responses, or support copy.
• Use WordPress capability checks such as manage_options for all connection management actions.
• Use nonces and OAuth state validation for browser-initiated connect/disconnect actions.
• Use PKCE where Cloudflare's selected flow and client type require or recommend it.
• Store token material server-side only, avoid autoloading sensitive/volatile connection data, and keep existing masking behavior for manual tokens.
• Provide a no-break migration for existing sites using the current Zone ID + API token settings.
• Handle multisite intentionally: document whether the connection is per-site or network-wide and enforce that in permissions/storage.
• Manual API token mode should include least-privilege guidance and validation for the required cache purge permission.

Acceptance criteria

• A technical design confirms the chosen Cloudflare-supported authorization flow and any required client registration, redirect/callback, domain verification, or hosted service requirements.
• The default UI presents connected account setup first and moves manual API token entry into advanced settings.
• Existing Cloudflare cache sync users continue working after update without needing to reconnect immediately.
• The purge path continues to call Cloudflare successfully for connected-account and advanced manual-token modes.
• The admin UI shows connected, disconnected, expired/revoked, insufficient-permission, and manual-mode states clearly.
• Tests cover token masking, permission checks, failed/revoked auth, missing permissions, legacy manual token fallback, and settings payload behavior.
• Public docs explain both the recommended connected flow and the advanced manual-token fallback without encouraging broad token permissions.

Non-goals

• Do not remove manual API token support in the same release.
• Do not require users to create a Cloudflare account from inside Perform.
• Do not broaden Cloudflare permissions beyond what cache purge and zone selection require.

Implementation notes

• Target base branch: release/1.9.0 once implementation starts. If that release branch does not exist yet, confirm the branch creation policy before opening a PR.
• This should be implemented as one or more focused PRs after the OAuth feasibility/design step is complete.
• Official references to review during design:
  • https://developers.cloudflare.com/fundamentals/oauth/
  • https://developers.cloudflare.com/fundamentals/oauth/create-an-oauth-client/
  • https://developers.cloudflare.com/fundamentals/oauth/integrate-with-cloudflare/
  • https://developers.cloudflare.com/fundamentals/oauth/authorizing-an-application/
  • https://developers.cloudflare.com/api/resources/cache/methods/purge/
  • https://developers.cloudflare.com/fundamentals/api/get-started/create-token/