Plan a database cleanup for a bloated WordPress site

A WordPress database has grown to 900MB on a site with maybe 1,200 real posts and
pages. A quick look shows:

[- wp_posts has roughly 250,000 rows total, most of them post_revision or auto-draft
- wp_options has 40MB of autoloaded data, including several rows over 1MB each
- wp_options has thousands of rows starting with _transient_ and _transient_timeout_,
many with timeout dates that already passed months ago
- No WP-CLI access confirmed yet, but phpMyAdmin access is available through the
hosting control panel]

ACTIVE PLUGINS: [WooCommerce, a page builder, a forms plugin, a caching plugin]

Build a cleanup plan like someone who has broken a site doing this carelessly before,
not a generic "delete revisions" checklist:
1. Diagnose what's driving the 40MB of autoloaded options specifically, since
   autoloaded bloat hurts every single page load, not just the admin. Name the likely
   culprits given this plugin stack, for example a page builder caching its full
   layout data in options, or a forms plugin storing submission logs there instead of
   a custom table.
2. Sequence the cleanup by risk: expired transients first since those are the safest
   to delete outright, then old revisions capped to keeping the last few per post
   rather than deleting all history, then autoloaded option bloat last since that
   needs identifying the source before touching it.
3. Give both a WP-CLI path (wp transient delete-expired, wp post delete for stray auto-
   drafts) and a direct SQL path for phpMyAdmin, since WP-CLI access isn't confirmed.
4. Insist on a full database backup and a maintenance-window warning before any bulk
   DELETE runs directly in phpMyAdmin, since a mistyped WHERE clause there has no undo.
5. Flag the edge case: some transients are intentionally long-lived, like a cached API
   response from a shipping-rate plugin. Blanket-deleting all transients rather than
   just expired ones can cause a wave of slow first-load API calls right after cleanup.