Add Version History / Change Tracking for Content Fragment Models

Problem / Current Limitation:
Currently, Content Fragment Models (CFMs) in AEM do not support version tracking. When a model's structure (fields, data types, validation rules, etc.) is modified, there is no way to see:

• What specifically changed (which field was added, removed, renamed, or had its type/config altered)
• Who made the change
• When the change was made
• Why the change was made (if a comment/reason was provided)

This creates accountability and governance gaps, especially in environments where multiple authors/developers manage models that drive content used across channels. Untangling the impact of a model change (e.g., a breaking change to a field type) after the fact is difficult or impossible today.

Proposed Enhancement:
Introduce native version history for Content Fragment Models, similar to how AEM Pages already support versioning. Specifically:

1. What to track:

   • Model structure changes: field additions/removals/renames, data type changes, validation rule changes, default values.
   • Metadata changes: title, description, tags.
   • Who made the change (author/user ID) and timestamp.
   • Optionally, a diff/comparison view between two versions.

2. How to acquire this information:

   • Leverage AEM's existing JCR versioning framework (mix:versionable) applied to the CFM node structure, similar to page versioning.
   • Capture change events via JCR observation / workflow launchers on cq:dialog/model node updates.
   • Store user and timestamp via standard jcr:lastModifiedBy / jcr:lastModified properties, extended to grant granular field-level diffs.

3. Where to store it:

   • Store versions in the JCR version history workspace (/jcr:system/jcr:versionStorage), consistent with existing AEM versioning patterns.
   • Expose version history through the Content Fragment Model editor UI (a "Version History" panel/timeline, similar to the Page Properties version tab).
   • Optionally expose via API (CFM Management API / GraphQL) so version history can be queried programmatically for audits.

Why it matters:

• Improves governance and accountability for teams managing shared content models across large organizations.
• Reduces risk of untracked breaking changes affecting content authors and downstream integrations (GraphQL persisted queries, headless delivery).
• Enables rollback to a previous model version when an unintended change causes issues.
• Aligns CFM capabilities with existing page/asset versioning features already in AEM.