FoundationDB connection string is not visible to tenants in the dashboard #4611

Describe the bug

A tenant cannot get the connection string of its FoundationDB from the dashboard. The fdb-kubernetes-operator writes the cluster file into the <release>-config ConfigMap, and since #4148 the tenant use, admin and super-admin roles may read exactly that ConfigMap. The console has no view for ConfigMaps, and the chart creates no Secret with a connection string, so nothing on the application page shows the cluster file. It is reachable only with kubectl.

Environment

• Cozystack v1.6.4, console cozystack-ui:v1.6.4
• Provider: on-prem, Talos

To Reproduce

1. As a tenant user with the use role, deploy a FoundationDB application.
2. Open the application page in the dashboard.
3. Look for the cluster file.

Expected behaviour

The application page shows the cluster file from <release>-config, with a way to copy it, to the users who can read that ConfigMap through RBAC.

Actual behaviour

No tab or field on the page shows it. kubectl -n tenant-<name> get configmap foundationdb-<name>-config -o jsonpath='{.data.cluster-file}' works for the same user, so RBAC is not the blocker anymore.

Logs

Not applicable: nothing fails, the data is just not shown.

Screenshots

Not applicable.

Additional context

• The chart already lists the ConfigMap in <release>-resourcemap, but nothing in the console reads that map. The map is also rendered only with monitoring.enabled: true, and the tenant role does not include it, so the console could not read it for a tenant even if it tried.
• fix(foundationdb): don't gate WorkloadMonitor behind monitoring.enabled #3490 keeps monitoring.enabled as the switch for the resource map and asks whether it should render unconditionally.
• External access to FoundationDB (the chart exposes no Service) is a separate topic and is not covered here.

Checklist

• I have checked the documentation
• I have searched for similar issues
• I have included all required information
• I have provided clear steps to reproduce
• I have included relevant logs