[danielpost]

Summary

Adds a "Post types" section to the settings page with a checkbox per public, REST-exposed post type — defaulting to Posts only. Enabling a type makes it eligible for sharing, registers Autoblue's post meta against it, surfaces the Autoblue editor panel on its edit screen, and pulls Bluesky replies into its native comments thread.

Closes the long-standing // TODO: Add support for multiple post types. in PostHandler and editor.js.

Backend

• Utils — new get_enabled_post_types(), get_available_post_types(), and sanitize_enabled_post_types() helpers. The sanitizer whitelists against the live public+REST post-type list and drops attachment (sharing media files isn't the use case).
• Admin — registers autoblue_enabled_post_types setting (array, default ['post']) with REST exposure and the Utils sanitizer.
• Meta — register_post_meta now loops over enabled post types instead of hardcoding 'post'.
• PostHandler — replaces the hardcoded valid_post_types guard with the accessor.
• Comments — replaces the hardcoded 'post' guard with the accessor so Bluesky replies surface on any enabled CPT's native comments thread.

Frontend

• Assets — ships availablePostTypes in the initial state (static metadata, not a setting).
• useSettings hook — surfaces enabledPostTypes / availablePostTypes / togglePostType, backed by useEntityProp on the new setting key (same pattern as the existing autoblue_enabled).
• Settings page — new "Post types" BaseControl section with a CheckboxControl per available post type.
• editor.js — switched to a useIsEnabled hook backed by useEntityProp so the gate is reactive and consistent with how the existing toggle is read. (Initial attempt used the inline-script initial state, but const autoblue = … creates a script-scoped lexical binding, not a window property — the store-backed approach sidesteps that entirely.)
• useShares hook — reads the current post type's rest_base from the core store and uses it in the poll path so the editor's post-publish status refresh works for any post type (was hardcoded to /wp/v2/posts/${id}, which 404'd on pages).

Confirmed design decisions

• The existing global "Automatically share posts to Bluesky" toggle stays global — one default-on value applies to every enabled post type. (Not per-CPT.)
• Comments integration follows the same enabled-CPT list — symmetric with sharing.
• Toggling a CPT off in settings does not destructively clean up existing autoblue_shares meta on already-shared content.

Test plan

• vendor/bin/codecept run wpunit — 44 tests / 104 assertions, all green (includes 5 new UtilsTest cases covering the accessor's defaults, stored values, non-array coercion, and the sanitizer's unknown-slug / attachment filtering)
• npm run build — clean
• vendor/bin/phpcs — clean
• End-to-end against the real install:
  • wp option get autoblue_enabled_post_types returns ['post'] by default
  • GET /wp/v2/settings exposes the new key with the array shape
  • Utils::get_available_post_types() lists Posts + Pages (attachment correctly filtered)
  • Sanitizer drops unknown slugs and attachment
  • Toggling Pages on in the settings UI propagates to the editor: the Autoblue panel appears on /wp-admin/post-new.php?post_type=page, the toggle works, and publishing a page with sharing on writes the autoblue_shares meta (404 on the post-publish status refresh confirmed fixed)