Allow plugins to register Push MD content adapters

Comienza leyendo Push_MD_Plugin::$supported_post_types y get_supported_post_types() en plugins/push-md/class-push-md-plugin.php, y luego sigue los flujos existentes de post/page y de las demás entidades mencionados en los criterios de aceptación. Define el contrato del adaptador y los límites del registro antes de la implementación; se considera terminado cuando un plugin independiente puede hacer round-trip de un CPT jerárquico conservando la validación, los permisos, las rutas, las vistas previas y el comportamiento existente de las entidades.

Problem

Push MD hardcodes the WordPress entities it exports and imports. Markdown post types begin with post and page, while Guidelines, raw block entities, and Global Styles are added through private type-specific branches in Push_MD_Plugin.

Current source: Push_MD_Plugin::$supported_post_types and get_supported_post_types().

A plugin cannot register its own content model with Push MD without modifying Push MD itself. Adding a post-type-name filter alone would be unsafe: path identity, hierarchy, metadata, taxonomy relationships, import validation, capabilities, branch previews, seeding, and collision handling must use the same contract.

Use case

The WP Docs proof of concept needs a private, hierarchical documentation post type to round-trip through Push MD while WordPress remains the content source of truth. Collections and topics must retain deterministic taxonomy relationships, and the documentation hierarchy must map to stable repository paths.

This should be solved as a generic Push MD extension point rather than a WP Docs special case.

Proposed direction

Add a fail-closed content-adapter registry that third-party plugins can populate before Push MD seeds or synchronizes its repository.

An adapter should define enough behavior for Push MD to apply one consistent contract across:

• entity discovery and supported statuses;
• stable path and identity mapping;
• serialization and parsing;
• hierarchy and dependency validation;
• taxonomy or other declared metadata relationships;
• create, update, move, and trash planning;
• read/edit/create/delete capability checks;
• branch preview projection where supported.

Push MD should continue to own Git protocol handling, stale-state checks, whole-push validation, path safety, collision rejection, atomic planning, repository persistence, and authentication. Adapters provide WordPress entity semantics, not alternate Git behavior.

The built-in post/page behavior should use the same registry where practical so extension behavior cannot drift from core behavior.

Acceptance criteria

1. A separate plugin can register a Markdown-backed hierarchical CPT without editing Push MD source.
2. Registration rejects duplicate adapter IDs, duplicate post types, reserved or colliding paths, invalid callbacks, and registration after the registry is frozen.
3. Seeder counts, WordPress export, path parsing, push planning/application, permission checks, and branch previews resolve through the registered adapter contract.
4. All incoming changes are parsed and validated before the first WordPress mutation; an adapter failure rejects the complete push.
5. Deterministic tests cover clone, update, create, hierarchy change, taxonomy relationships, collision rejection, stale push rejection, and trash behavior for a plugin-defined CPT.
6. Existing posts, pages, templates, template parts, navigation, Global Styles, and Guidelines retain their current repository paths and behavior.
7. Public extension documentation includes a minimal third-party adapter example and lifecycle timing.

Consumer

Tracked WP Docs work: chubes4/wp-docs#19.