Audit logging and eventing for track changes

Add audit logging and eventing for track changes

Parent epic: dotCMS/core#35693 · Workstream B (Self-service) · Post-launch

Background

Track changes affect what version an environment runs, so the epic requires an audit trail (who changed what, when) and useful eventing so customer CI pipelines can react. This covers both the audit record and the outbound webhook/system event.

Scope

• Write an audit record on every track change: actor, environment, old track, new track, timestamp, source (API/UI/support).
• Emit a system event / webhook when a track changes and (where feasible) when a tracked update is applied to an environment.
• Define the event payload shape and document it for customers.
• Ensure audit records are queryable for support and compliance.

Out of scope

• The plugin-failure-on-update notify/hold behavior (epic flags this may be its own epic).
• Dashboards (#36533).

Acceptance criteria

• Every track change writes an audit record with actor/env/old/new/timestamp/source.
• A documented event/webhook fires on track change.
• Audit records are queryable.
• Event payload documented for customers.

Depends on

• #36528 (change path to hook into).

Related

• Consumed indirectly by #36529 (changes made via API must be audited).

Part of the Evergreen Release Tracks epic. Parent: #35693.

Start with the change path described in #36528 and trace where track changes are handled. Define the audit and event/webhook payloads, then document them for customers and verify that audit records are queryable. Done means all listed acceptance criteria are met without including the out-of-scope notification behavior.