Analytics: Environment Filtering — Dashboard: environment selector in the analytics portlet

Summary

Add an environment selector to the Angular analytics dashboard portlet, fully driven by dotCMS core's new config endpoint, defaulting to the current environment, with zero hardcoded environment names.

Parent epic: #37349
Spike: #37107
Depends on: the dotCMS-core sub-task's config endpoint ({current, available:[{key,label}]}) and the CAEM query API sub-task's environment parameter (otherwise the selector has nothing to filter).

Background

• Location: core-web/libs/portlets/dot-analytics/portlet/ — add the selector near the existing filters in .../shared/components/dot-analytics-filters/.
• Pattern to reuse: core-web/libs/ui/src/lib/dot-site-selector/ — a PrimeNG dropdown directive already solving the adjacent "switch what you're looking at" UX for site-switching. Reuse the pattern (dropdown + label + loading state), not the code — it's site-scoped, not environment-scoped, and has no A/B-testing-style prior art to borrow (confirmed in the spike: ExperimentsAPIImpl pulls from CubeJS, not CAEM/ClickHouse, and has no Production/Authoring correlation logic at all).
• Data flow: dot-analytics.service.ts gains a call to the new config endpoint to populate the dropdown, and appends &environment=<selected> to its existing calls against /api/v1/analytics/{events,sessions,content}.
• Default selection: current environment (DOT_ANALYTICS_ENVIRONMENT, surfaced as current in the config response) — matching today's implicit behavior as closely as possible. The user has to actively choose to cross-view another environment; it's never thrust on them by default.
• Label handling: the label shown for whichever entry is current isn't a friendly name pulled from config — it's a fixed, locally-defined UI string ("Current env") substituted in wherever item.key === current. That's a trivial equality check, not environment-naming logic — the UI still never computes which key is current or invents a display name for one.
• No hardcoded environment names anywhere — the dropdown is fully driven by the available list from the config endpoint. Non-prod naming is confirmed inconsistent across customers even for what maps to "production" (greatclips: prod/dev/qa; tylertech: prod/dev/auth/staging) — a hardcoded PROD option, as the original ticket's working hypothesis proposed, would be wrong or absent for a meaningful slice of customers.

Scope

• Environment-selector dropdown component in dot-analytics-filters, reusing the dot-site-selector interaction pattern.
• Loading state while the config endpoint call is in flight.
• Default-to-current-environment behavior on portlet load.
• Wire selector changes into dot-analytics.service.ts's existing query calls (&environment=<selected>).

Out of scope

• Any environment-naming or "which one is current" logic in Angular — that's entirely server-computed (dotCMS-core sub-task).
• Authorization/visibility rules for which environments a given user may select — explicitly deferred by the epic (CAEM auth stays tenant-scoped; no product answer yet on who may view Production data from Authoring).
• Environment as a reporting/breakdown dimension (side-by-side prod vs. staging) — epic scope is one selector that scopes the whole dashboard, not per-metric environment breakdowns.

Dependencies

Blocked on the dotCMS-core config endpoint's response contract being stable, and on the CAEM query API accepting &environment= for the selection to actually filter returned data (otherwise the selector would silently do nothing — worse than not having it, per the spike's explicit sequencing note).

Acceptance Criteria

• Selector renders, populated entirely from the config endpoint's available list, no hardcoded names
• Defaults to current on load; user must actively select a different environment to cross-view
• Selecting an environment updates every metric/dimension shown on the dashboard (epic acceptance: "not a subset")
• Current-environment entry shows the fixed "Current env" label, not a config-sourced label
• Loading state handled gracefully while the config call is in flight

Next step

Run /speckit-specify against this issue to produce the formal spec (component structure, exact service changes) before implementation.