DataguardBroker stuck in Creating — FindPods requires primary and standby to run the identical container-image string

[AgnosticDBA]

Environment

• OraOperator: v2.1.0
• Kubernetes: k3s v1.35.5 (single node), containerd
• Database image: Oracle Database 23ai (23.26.1) Enterprise Edition

Summary

DataguardBroker reconciliation can never find the standby's pod — and the CR sits in Creating
forever — if the standby SingleInstanceDatabase runs a different image string from the primary,
even when the pod is 1/1 Running and healthy.

Steps to reproduce

1. Create a primary SIDB with image string A (e.g. oracle/database:23.26.1-ee).
2. Create a physical-standby SIDB with a different image string B (e.g. a thin overlay tag
   oracle/database:23.26.1-ee-dgfix) — a common pattern when the standby needs a patched
   entrypoint.
3. Create the DataguardBroker.

Actual

The leader logs, while the standby pod is 1/1 Running:

Total No Of gold-standby PODS  Count: 0
no ready Pod for the singleinstancedatabase

In v2.1.0, setupDataguardBrokerConfiguration calls
FindPods(r, sidb.Spec.Image.Version, sidb.Spec.Image.PullFrom, standbyDatabase.Name, ...) using the
primary's sidb image, and FindPods filters with exact equality
pod.Spec.Containers[0].Image == image (commons/database/utils.go:326 in v2.1.0). The standby's
container image string differs from the primary's, so it matches zero pods.

Expected

The broker should locate the standby's ready pod by SIDB identity (name / owner reference / labels),
not by requiring the two databases to share an identical image string. A standby legitimately may run
a different image (e.g. a patched entrypoint) while being the correct DG member.

Suggested fix

Match the standby pod by the standby SIDB's own image/labels (or by owner reference), rather than by
the primary's Image.PullFrom.

Workaround

Make both SIDBs use the same image string (point the standby CR at the primary's tag). If the
standby needs different content, deliver it by re-importing the patched layers over the same tag in
the node's container runtime so the string is unchanged.