feat(admin-ui): surface error/warning logs in production for environment diagnostics

[faisalsiddique4400]

Context

Today the Admin UI logs only through devLogger, which is gated and no-ops in production. Errors and warnings (e.g. Cedarling configuration warnings around the rawMessage constant in the Cedarling client) are therefore invisible in a deployed/upgraded Flex installation. User-facing feedback is limited to toasts, with a character limit.

This surfaced concretely: a client who upgraded Flex to 2.0.0 is hitting a Cedarling-related error. They run the packaged Admin UI build — they cannot add a devLogger.warn(...) line and rebuild to diagnose it. So the failure is effectively silent for them and for support.

Problem

• devLogger being prod-suppressed means real environment/config errors leave no trace in the browser console of a deployed instance.
• Toasts are for short, clear user messages — not a substitute for diagnostic logging, and not appropriate for raw/unclear error text.
• We need a way for clients and support to see what went wrong in production without modifying the build.

Proposed direction (to confirm on call)

Revisit the "no console logs in production" stance and split logging by intent:

1. Errors & environment/config warnings → always reach the browser console in production. Caught exceptions, failed initialisation (Cedarling, license, Config API reachability), unexpected states. This is standard practice and costs nothing to ship.
   • Guardrail: scrub secrets/PII (tokens, inum, full URLs with creds) from anything logged.
2. devLogger stays for verbose/dev-only breadcrumbs — unchanged, still gated.
3. Toasts — keep for short, clear, actionable user messages. Add toasts on API-call failures / rejected data where they're currently missing, but never dump raw error bodies or stack traces into them. Optionally include a short error/correlation id.
4. (Stretch) Consider a bounded in-memory log buffer + a Diagnostics screen with "download log file", so on-prem admins can hand support a file without console access.

Concrete first step (the trigger case)

In the Cedarling client, after the rawMessage constant (~line 169):

devLogger.warn('Cedarling Warning: ' + rawMessage)