refactor(2meet-data-optimizer): resolve post_type/group/table mappings through the registry

- TMDO_Post_Fields::post_type_for_group() / groups_for_post_type() derive HivePress-style groups from their registry post_type scope (core keeps its own attachment / wc_product / nav_menu_item map); the three copy-pasted switches and the query router's POST_TYPE_GROUP_MAP use them
- Term/comment backfill, shadow verifier and CLI take their groups from the registry (TMDO_Term_Comment_Backfill::registered_groups()); installer drops the hp_* entries already covered by its table patterns; REST listings default post type is filterable (tmdo_rest_default_post_type, default 'post')
- Verify: NoHpMappingsTest guard + mapping/default tests; core unit 640 / integration 449, HP 146/49, WC 10/22 OK
- PR: PR-020e

includes/migration/class-tmdo-post-migration.php

@@ -546,8 +546,8 @@ final class TMDO_Post_Migration {
 	}
 
 	/**
-	 * Map group name to the post_type it targets. The mapping is canonical
-	 * to v2.9.1 group definitions in TMDO_Post_Fields.
+	 * Map group name to the post_type it targets (see
+	 * TMDO_Post_Fields::post_type_for_group()).
 	 *
 	 * Returns null for cross-post_type groups (e.g. 'wp_core').
 	 *
@@ -555,23 +555,7 @@ final class TMDO_Post_Migration {
 	 * @return string|null
 	 */
 	private static function group_post_type( string $group ): ?string {
-		switch ( $group ) {
-			case 'attachment':
-				return 'attachment';
-			case 'wc_product':
-				return 'product';
-			case 'hp_listing_core':
-				return 'hp_listing';
-			case 'hp_request_core':
-				return 'hp_request';
-			case 'hp_vendor_core':
-				return 'hp_vendor';
-			case 'nav_menu_item':
-				return 'nav_menu_item';
-			case 'wp_core':
-			default:
-				return null;
-		}
+		return TMDO_Post_Fields::post_type_for_group( $group );
 	}
 
 	/**