How to categorize this issue?

/area monitoring
/kind bug

What happened:

With #12476 (602d934), the plutono-datasources ConfigMap is no longer mounted into the garden/plutono deployment (e.g., on Seeds) but dynamically loaded by the sidecar.
However, it is still marked as unique (immutable + garbage collectable). With this, the garbage collector will delete the ConfigMap, even though it is still in use.

What you expected to happen:

The ConfigMap should not be collected by the garbage collector.

How to reproduce it (as minimally and precisely as possible):

1. make kind-up gardener-up
2. Wait for the garden/plutono-datasources-* ConfigMap to be 10m old (minimum lifetime for garbage collection)
3. Trigger the garbage collection: k -n garden delete po -l app=gardener-resource-manager
4. Observe that the ConfigMap is deleted:

stern -n garden resource-manager | grep garbage
...
gardener-resource-manager-fc45c7c75-57jr2 gardener-resource-manager {"level":"info","ts":"2025-08-18T15:13:38.718Z","msg":"Delete resource","controller":"garbage-collector","namespace":"","name":"","reconcileID":"646631aa-b91c-4c31-983a-d1543ce02236","kind":"configmap","namespace":"garden","name":"plutono-datasources-57f18467"}
...

Anything else we need to know?:

Although the ManagedResource will immediately recreate the ConfigMap, it has an error like Required ConfigMap "plutono-datasources-57f18467" in namespace "garden" – at least temporarily.
We observed this error in the SeedSystemComponentsHealthy condition for long enough to trigger alerts 😄

Environment:

• Gardener version: v1.124.2
• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• Others: