Allow plugins to register Push MD content adapters

首先阅读 plugins/push-md/class-push-md-plugin.php 中的 Push_MD_Plugin::$supported_post_types 和 get_supported_post_types()，然后跟踪验收标准中所述的现有 post/page 及其他 entity 流程。在实现之前定义 adapter contract 和 registry 边界；当一个独立 plugin 能够对 hierarchical CPT 执行 round-trip，同时保留 validation、permissions、paths、previews 以及现有 entity behavior 时，即视为完成。

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.