Define and enforce CNPG version compatibility for BYO mode

[WentingWu666666]

Context

PR #379 introduced a toggle that lets users opt out of the bundled CloudNative-PG installation and bring their own (BYO mode). Today, when users enable BYO, the DocumentDB operator runs against whatever CNPG version they already have installed which could be older or newer than what we test against.

There is currently no declared supported CNPG version range, no runtime detection, and no enforcement. Out-of-range combinations will likely fail in subtle ways at runtime (silent backup skips, replication issues, restore problems) that look like DocumentDB operator bugs but are actually version mismatches.

Goal

Make the BYO compatibility contract explicit, testable, and enforceable before BYO is recommended in user-facing documentation.

Out of scope

• Defining the specific implementation open to the assignee's design.
• Supporting every CNPG version that ever existed. The point is a clear, narrow, well-tested range.

References

• PR feat: allow using an existing Cloudnative PG operator #379 introduced the BYO toggle this issue tracks.

[documentdb-triage-tool]

🤖 Auto-triaged by documentdb-triage-tool.

Applied: go
Project fields suggested: Component controllers · Priority P2 · Effort L · Status Triage
Confidence: 0.75 (llm)

Reasoning

LLM: Defining, detecting, and enforcing a CNPG version compatibility contract for BYO mode touches runtime logic, validation, and potentially schema/config, spanning multiple files across the operator internals.

If a label is wrong, remove it manually and ping @patty-chow so the rules can be tuned. The bot will not re-label items that already have component labels.