[Epic] Release Tracks self-service: Cloud Console/UI, public API, customer-initiated track changes

Description

Summary

Deliver the customer-facing self-service layer for dotCMS Cloud Release Tracks: the surface/auth decision, the Release Track Picker UI, a public REST API, audit logging/eventing, and making persisted assignments the source of truth for the fleet.

This is the follow-on to [Epic] Release Tracks v1 (#35693) — a related feature, deliberately not a sub-issue. In v1, tracks are fully operational but changes are made by dotCMS: customers request a track change via a support ticket ("contact support"), actioned per the interim support runbook. This epic replaces that interim flow with self-service.

User Story

As a dotCMS Cloud customer with multiple environments,
I want to view and change each environment's Release Track myself — in a UI or via API —
so that I can manage my update posture without filing a support ticket.

Scope

• Surface + auth ADR (decide first — gates everything below): dotAdmin portlet vs. a new dotCMS Cloud Console; authn model (federated SSO/SAML, OIDC, relationship to dotAdmin identities). Tracked in dotCMS/private-issues#654.
• Release Track Picker UI from the existing design: current track, available tracks with plain-English descriptions, current version per track, expected next-update window, confirmation flow (incl. "moving slower does not roll back"). (#36531)
• Public REST API to read and update an environment's track, with appropriate authn/authz, supporting customer CI/CD automation. (#36529)
• Audit logging + eventing for track changes — who changed what, when; webhook/system event for customer pipelines. In v1 the audit trail is git history in infrastructure-as-code; a formal audit surface only becomes meaningful with an API. (#36530)
• Persistence as source of truth: reconcile every environment's persisted assignment against its deployed track, make API/persistence authoritative over the interim manifest-label approach, cut the support runbook over to the API/UI. (dotCMS/infrastructure-as-code#7988)

Out of scope

• Customer-selectable update cadence (when tracks advance) — future.
• Pin-to-version, future-dated updates, plugin pre-flight checks, custom health-check gating, mission-critical flags — future (unchanged from #35693's deferred list).
• Self-hosted / on-prem support.
• The track mechanics themselves (floating tags, promotion engine, reconciler) — shipped and operated under #35693.

Public API (sketch, carried from #35693)

GET    /api/v1/environments/{id}/release-track
PUT    /api/v1/environments/{id}/release-track   { "track": "standard" }
GET    /api/v1/release-tracks                    # list available tracks

Exact shape and authentication model depend on the surface/auth ADR.

Acceptance criteria

• Surface + auth ADR decided and documented (dotCMS/private-issues#654).
• Customer can view and change an environment's track in the UI, with confirmation flow and audit trail.
• Public REST API supports read + update with documented authn/authz.
• Track changes emit an auditable event.
• Persisted assignment is authoritative; fleet reconciled; support runbook cut over from manifest edits to the API/UI.
• "Contact support" remains a working fallback throughout rollout.

Links

• Related epic (v1, launch mechanics + support-driven changes): #35693
• Design mockup: Release Track Picker (internal)

Begin with the surface and authentication ADR in dotCMS/private-issues#654, then review the related UI and API issues #36531 and #36529. Use the audit, persistence, and rollout requirements in this epic to map the work. Done means the acceptance criteria are met, including UI and API changes, auditable events, authoritative persisted assignments, and the support fallback.