Add database cleanup diagnostics with backup-first cleanup workflow

Summary

Add database cleanup diagnostics with a backup-first cleanup workflow, and make PerformWP's existing revision-limit behavior reliable for both newly created revisions and accumulated historical revisions.

The current revision setting uses WordPress's wp_revisions_to_keep filter. That can govern future retention, but it does not provide a bounded cleanup path for revisions accumulated before activation or while enforcement was incomplete.

Evidence

A local WordPress performance audit found:

• Total database size: 93,454,336 bytes
• wp_posts: approximately 47.58 MB
• Revisions: 1,487 rows
• Revision post content: approximately 38.08 MB

This makes revision retention and historical cleanup a material part of the broader database-cleanup workflow.

Proposed scope

• Scan for common WordPress database clutter:
  • expired transients
  • old post revisions
  • auto-drafts
  • trashed posts
  • orphaned postmeta/commentmeta/usermeta
  • table overhead where detectable
• Show counts and estimated size impact before any cleanup.
• Allow one category to be cleaned at a time.
• Create a backup or rollback artifact before destructive cleanup.
• Link cleanup actions into the safe optimization history.

Revision-limit reliability

• Audit the current wp_revisions_to_keep integration and confirm the configured limit is honored per supported post type after repeated saves.
• Retain the newest N revisions and preserve the current post.
• Define behavior for autosaves, revisions created before PerformWP activation, disabled/unlimited values, custom post types, and multisite.
• Provide a deliberate cleanup path for existing excess revisions.
• Process historical cleanup in bounded, resumable batches using WordPress deletion APIs rather than one unbounded delete query.
• Run cleanup only through an explicit admin/settings action or idempotently scheduled background job, never on every public request.
• Report progress, completion, partial failure, and safe retry state.

Safety requirements

• No automatic cleanup on activation.
• No revision cleanup on normal public requests.
• Destructive actions require capability checks, nonce checks, explicit confirmation, and backup/rollback guidance.
• Preserve current posts and the newest configured revision set.
• Do not expose private content values in diagnostics or logs.
• Multisite behavior must be explicit.
• Very large sites must receive warnings before expensive scans.
• Cleanup scheduling and retries must be idempotent.

Acceptance criteria

• Admin users can run a read-only database clutter scan.
• Scan results show category counts, estimated size impact, and plain-language risk notes.
• The configured revision limit is honored per supported post type after repeated saves, retaining the newest N revisions.
• Tests explicitly cover autosaves, pre-activation revisions, disabled/unlimited values, custom post types, and multisite behavior.
• Existing excess revisions can be removed in bounded batches through WordPress deletion APIs.
• Historical cleanup can resume safely after interruption without deleting retained revisions twice.
• Cleanup actions are category-scoped, confirmed, capability/nonce protected, and logged.
• Completion and failure states are visible and actionable.
• Backup and rollback guidance is documented and validated before destructive cleanup.
• Automated coverage includes future limit enforcement and batched historical cleanup.
• A high-count fixture comparable to 1,487 revisions / 38.08 MB records revision count and database-size impact before and after cleanup.
• Validation covers empty sites, high-count sites, permissions, failed cleanup recovery, and multisite.

Non-goals

• Running cleanup automatically on activation or every request.
• Deleting all revisions without retaining the configured newest set.
• Using one unbounded direct SQL delete for historical cleanup.
• General database optimization beyond the categories already listed in this issue.

Implementation and validation notes

Prefer WordPress deletion APIs so revision metadata and related hooks remain consistent. Bound each cleanup batch by count and runtime, persist progress safely, and make retries idempotent. Capture before/after counts and size estimates without logging post content.

Any production cleanup remains a destructive owner action and must require explicit confirmation at runtime; this issue does not authorize cleanup of an existing site.

Start by auditing the existing wp_revisions_to_keep integration and the plugin's admin/settings action. Map the WordPress deletion APIs, revision-limit behavior, and the acceptance-test cases for autosaves, custom post types, multisite, and interrupted batches. Done means read-only diagnostics, protected category-scoped cleanup, resumable progress, and validated backup guidance.