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).

Inizia leggendo Push_MD_Plugin::$supported_post_types e get_supported_post_types() in plugins/push-md/class-push-md-plugin.php, quindi segui i flussi esistenti di post/page e delle altre entità indicati nei criteri di accettazione. Definisci il contratto dell’adapter e i confini del registry prima dell’implementazione; il lavoro è completato quando un plugin separato può eseguire il round-trip di un CPT gerarchico preservando la validazione, i permessi, i percorsi, le anteprime e il comportamento delle entità esistenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.