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

[sfreudenthaler]

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"). (Release Track Picker UI from the existing design #36531)
• Public REST API to read and update an environment's track, with appropriate authn/authz, supporting customer CI/CD automation. (Public REST API for per-environment release track #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. (Audit logging and eventing for track changes #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 [Epic] Release Tracks: per-environment update channel selection #35693's deferred list).
• Self-hosted / on-prem support.
• The track mechanics themselves (floating tags, promotion engine, reconciler) — shipped and operated under [Epic] Release Tracks: per-environment update channel selection #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): [Epic] Release Tracks: per-environment update channel selection #35693
• Design mockup: Release Track Picker (internal)