refactor(2meet-data-optimizer): list post groups for backfill from the registry

- Admin "backfill all" and `wp tmdo post-migrate-group` take any registered post group via TMDO_Post_Migration::backfillable_groups() instead of a hard-coded list of 7 (dev36 registers 11; the 4 HP add-on groups were never backfilled). Restored orphan groups are excluded and rejected — their values live only in the flat table.
- Groups with json fields (attachment, nav_menu_item) go row by row through the migration engine instead of leaving the json columns NULL in the bulk pivot.
- Verify: PostBackfillJsonTest (3 RED on hardening/2.2); dev36 post-migrate-group attachment / nav_menu_item / hp_draft_flags: json columns semantically equal native (24/24, 21/21), checker unchanged.
- PR: PR-067

cli/class-tmdo-cli-post.php

@@ -198,25 +198,16 @@ class TMDO_CLI_Post {
 
 	/**
 	 * Backfill one post entity group from wp_postmeta into its flat table
-	 * via a single bulk SQL pivot (ON DUPLICATE KEY UPDATE).
+	 * via a single bulk SQL pivot (ON DUPLICATE KEY UPDATE). Groups with
+	 * JSON-typed fields are backfilled row by row instead.
 	 *
-	 * Idempotent — safe to re-run. Skips JSON-typed fields (handled by the
-	 * row-by-row backfill phase in v2.9.4+).
+	 * Idempotent — safe to re-run.
 	 *
 	 * ## OPTIONS
 	 *
 	 * --group=<group>
-	 * : Entity group name. Required.
-	 * ---
-	 * options:
-	 *   - wp_core
-	 *   - attachment
-	 *   - wc_product
-	 *   - hp_listing_core
-	 *   - hp_request_core
-	 *   - hp_vendor_core
-	 *   - nav_menu_item
-	 * ---
+	 * : Registered post entity group name (e.g. wp_core, attachment,
+	 * hp_listing_core). Required.
 	 *
 	 * ## EXAMPLES
 	 *