Allow plugins to register Push MD content adapters

## 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()`](https://github.com/Automattic/php-toolkit/blob/02e19f0559d48359ce62183e993e722362732050/plugins/push-md/class-push-md-plugin.php#L53-L122).

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](https://github.com/chubes4/wp-docs/issues/19).

Start by reading Push_MD_Plugin::$supported_post_types and get_supported_post_types() in plugins/push-md/class-push-md-plugin.php, then trace the existing post/page and other entity flows named in the acceptance criteria. Define the adapter contract and registry boundaries before implementation; done means a separate plugin can round-trip a hierarchical CPT while preserving validation, permissions, paths, previews, and existing entity behavior.

Written by the indexing model from the issue text.