feat: Add default affinity to OPA server Pods

[marc-merino]

Description

Prefer scheduling Kafka broker Pods on nodes that run the configured OPA cluster's server Pods. When OPA authorization is configured, the broker's default affinity gains a preferred Pod affinity term with weight 50, hostname topology, and the OPA server role labels. The existing broker anti affinity and role/role group override merge order remain unchanged. KRaft controllers do not use the OPA authorizer, so their placement remains unchanged.

The OPA discovery ConfigMap is named after the OpaCluster and is read in the KafkaCluster's namespace. The preference affects scheduling only; it does not guarantee co-location or change service routing.

This follows the approach in trino-operator#924 and addresses the consuming-operator request in opa-operator#525. Companion change: hbase-operator#814.

Verification

• cargo build — passed.
• cargo test -p stackable-kafka-operator crd::affinity::tests -- --nocapture — passed (3 tests).
• cargo test -p stackable-kafka-operator — 121 passed, 1 failed: quorum_manager_defers_while_an_existing_voter_is_stale. It fails identically on unmodified main in the same macOS environment (run with a local timeout substitute), so it is unrelated to this change.
• cargo +nightly-2026-08-23 fmt --all -- --check — passed.
• cargo clippy --all-targets -- -D warnings — passed.
• Kubernetes integration tests were not run because no cluster is available.

Definition of Done Checklist

Author

• No CRD field changes.
• Release note snippet added.
• Integration tests passed (requires a Kubernetes cluster).

Reviewer

• Code comments explain the OPA ConfigMap naming and namespace assumption.
• Unit tests cover OPA enabled and disabled defaults and controller exclusion.
• Documentation updated.
• Changelog updated.

[stackable-cla]

All committers have signed the CLA.

[NickLarsenNZ]

Hi @marc-merino, any reason why you closed this?

[marc-merino]

Hi @NickLarsenNZ, an agent of mine malfunctioned and opened this PR and the companion HBase PR.

I was attempting a cross-repo change using knit, but this was my first time trying the workflow on an OSS project, and fork support didn't exist yet, so the agent went rogue.

I've also found a couple of other issues that seem better suited to the cross-repo workflow: one that's close to an ideal use case and another that also looks like a good fit.

I haven't opened PRs for neither yet because I want to review them properly before adding any additional noise, currently reviewing the first one. Sorry for this.

[NickLarsenNZ]

No worries. Thanks for answering (we were just rather curious)