feat(37659): frontend limited-mode UI and analytics health gate (FE)

[freddyDOTCMS]

Summary

Angular/TypeScript implementation of the limited-mode UI and analytics health response mapping. Depends on the BE PR: #37690.

Analytics portlet:

• HealthEntity type updated — adds health field (OK|NOT_CONFIGURED|CONFIGURATION_ERROR); legacy available field preserved for rollback safety
• DotAnalyticsService.healthCheck() maps health field first, falls back to available
• analyticsHealthGuard allows on HealthStatusTypes.OK (was AVAILABLE)
• Resolver extracts health field from full ExperimentsHealthResponse to preserve downstream contract

Experiments portlet:

• ExperimentsHealthResponse interface — healthCheck() now returns tier, freeExperimentUsed, warning in addition to health
• Store: three new computed signals — isLimitedMode, isSlotUsed, showAnalyticsWarning
• List: non-closable limited-mode banner (info/warn based on slot state); closable analytics-warning banner; Archive/End/Cancel/Abort show info toast instead of disabled state (tooltip-invisible)
• Configure scheduling: blocked by p-blockUI in limited mode with explanatory message; scheduling cleared by effect before _start so the BE sees no dates (prevents SCHEDULED instead of RUNNING)
• Configure footer: Start button disabled when tier=LIMITED && freeExperimentUsed=true
• Configure header + Results header: Stop Experiment shows info toast in limited mode

Test plan

• pnpm nx test portlets-dot-analytics-data-access — 220 tests passing
• pnpm nx test portlets-dot-analytics — 335 tests passing
• pnpm nx test portlets-dot-experiments-portlet — 1407 tests passing
• Manual: switch server to FEATURE_FLAG_EXPERIMENTS=false, verify limited-mode banners and blocked actions in the Experiments portlet
• Manual: verify Analytics portlet health guard redirects correctly for NOT_CONFIGURED and CONFIGURATION_ERROR

🤖 Generated with Claude Code

This PR fixes: #37659

[claude]

Claude finished @freddyDOTCMS's task in 2m 25s —— View job

---

Code Review — limited-mode UI & analytics health gate (FE)

New Issues

• 🟠 High: core-web/libs/portlets/dot-experiments/portlet/src/lib/dot-experiments-configure/dot-experiments-configure.component.html:92 — Stray o character prepended to the line: o [gated]="$isGated()". Angular parses this as a bogus static attribute o on <dot-experiments-configure-scheduling> and ships it to the DOM. It compiles (so tests/build stay green) but it is clearly an unintended edit artifact and should be removed. Fix this →

• 🟠 High: core-web/libs/portlets/dot-experiments/portlet/src/lib/dot-experiments-configure/components/dot-experiments-configure-footer/dot-experiments-configure-footer.component.ts:6 — import { map } from 'rxjs/operators' is unused — the footer builds #healthResponse with toSignal(...healthCheck(), { initialValue: null }) and never pipes map. CI runs nx affected -t lint and an unused import fails the build. (The header, results-header, and configure components all use their map import; only the footer imports it without use.) Fix this →

• 🟡 Medium: core-web/libs/portlets/dot-experiments/portlet/src/lib/dot-experiments-configure/dot-experiments-configure.component.ts:588-597 — The doc block ending …would turn one save into a round trip. documents mirrorFormEffect, but the new clearSchedulingInLimitedModeEffect was inserted directly beneath it (with its own /** … */). The original comment now dangles detached above the wrong member. Move it back to sit directly above mirrorFormEffect.

• 🟡 Medium: duplicate health requests on the configure screen. dot-experiments-configure.component.ts:194, …configure-footer.component.ts:75, and …configure-header.component.ts:195 each independently call inject(DotExperimentsService).healthCheck() via toSignal. Since all three render together on the configure screen, opening it fires GET /api/v1/experiments/health three times (the results screen adds two more). Consider resolving tier/freeExperimentUsed once (route resolver or the configure store) and passing it down, rather than one HTTP call per component. Not a correctness bug, but wasteful and racy if the three responses ever disagree.

• 🟡 Medium: core-web/libs/portlets/dot-experiments/portlet/src/lib/dot-experiments-list/dot-experiments-list.component.html:36 — The showAnalyticsWarning banner lives in the @else branch, which only renders when isMisconfigured() is false, i.e. health === OK. Assumption: the warning is meant for the "Analytics App not configured" case, where health is NOT_CONFIGURED and isMisconfigured() is true — in which the misconfiguration empty-state renders instead and this banner is never seen. What to verify: confirm with the BE contract (spec: Feature-flag gates for analytics and experiment endpoints (#37659) #37690) whether warning: 'analytics_disabled' is ever returned together with health: OK; if not, this banner is unreachable.

Notes

• The health-first / available-fallback mapping in dot-analytics.service.ts and the ExperimentsHealthResponse extension are clean and well-tested; the legacy fallback paths have explicit coverage.
• clearSchedulingInLimitedModeEffect settles after one extra run (the $model write re-triggers the effect, but the second pass finds dates already null and no-ops) — no infinite loop. Good.

Blocking: the two 🟠 High items (stray o, unused map import) should be fixed before merge.
· issue-37659-analytics-experiment-flag-gates-fe