Track Coroot instance binding after database Pod rescheduling #4720

🤖 Generated by the Agentic Engineer

Problem

Coroot can keep an operator-managed database Pod attached to its old node when a same-named replacement appears on a different node within the selected time window. The resulting missing metric join can misreport instance availability until the old samples age out.

Scope

Build a synthetic regression for the Kubernetes metadata and container-metric join, then contribute the smallest necessary correction to coroot/coroot. Preserve real outage reporting and existing non-Kubernetes instance behavior. Track upstream merge, release availability, platform adoption, and post-adoption evidence separately.

Upstream necessity and boundary

The incorrect identity merge is in Coroot's public model and constructor, not in the platform's workload configuration. Changing database placement or rewriting telemetry would not correct that model and could hide real signals. The maintainer has already authorized Coroot contributions. This is public-source research and a sanitized contribution to Coroot, not employment-related work; no private source, cluster identifiers, logs, or credentials will be published.

Acceptance

• A regression demonstrates distinct same-named operator Pods on two nodes, including metric attachment.
• The proposed fix preserves same-node reuse, StatefulSet behavior, and non-Kubernetes instances.
• Required upstream tests and lint pass, with a clean private exact-head review.
• The platform remains unmodified until an upstream release is available and reviewed adoption is verified live.

Part of #2043.