Add admin-ajax and Heartbeat diagnostics with safe throttling options

Summary

Add diagnostics for admin-ajax and Heartbeat activity, then extend Perform’s controls with safer per-screen or per-context throttling options.

This should help site owners understand background admin activity before changing behavior.

Why this matters

Slow admin experiences are often affected by repeated AJAX requests, Heartbeat polling, autosave, post locks, editor activity, dashboard widgets, and plugin-specific background checks. Blanket throttling can break editing workflows, so Perform needs visibility first and careful controls second.

Proposed scope

• Add admin diagnostics that summarize repeated admin-ajax.php and Heartbeat activity.
• Show request/action frequency where safe to identify.
• Distinguish Heartbeat, autosave/editor contexts, and generic AJAX where possible.
• Add per-screen or per-context Heartbeat recommendations.
• Consider safe presets such as:
  • dashboard/admin list screens: slower Heartbeat interval
  • post editor screens: preserve editing safety and autosave expectations
  • WooCommerce/order or commerce-like screens: avoid aggressive throttling by default
• Provide clear warnings before users change settings that affect editor/session behavior.

Safety requirements

• Do not break autosave, post locking, or active editor collaboration flows.
• Do not log request payloads, nonces, user data, or private query values.
• Keep aggregate data bounded and resettable.
• Any throttling must be opt-in and reversible.
• Capability checks must guard diagnostics and settings.

Acceptance criteria

• Perform can show aggregate admin-ajax and Heartbeat activity when diagnostics are enabled.
• The UI explains which activity is informational versus actionable.
• Any new throttling setting is scoped, reversible, and documented.
• Editor screens preserve safe defaults.
• Tests or runtime validation cover disabled mode, diagnostics mode, editor screen behavior, and settings persistence.

Implementation notes

This should build on existing Heartbeat-related controls rather than duplicating settings. The first implementation may be diagnostics-only if safe throttling scope needs a separate follow-up.

Start by locating the existing Heartbeat-related controls and trace how their settings are stored and guarded by capability checks. Define a bounded diagnostics-only first slice if safe throttling remains too broad, then validate disabled mode, diagnostics mode, editor-screen behavior, persistence, and the safety requirements described in the acceptance criteria.