fix: reconcile KafkaBackup resources into scheduled CronJobs

[sionsmith]

Summary

• force server-side apply for the fully generated, operator-owned backup CronJob so stale field ownership cannot block KafkaBackup spec changes
• add a reconciler regression test covering spec.resources propagation and the forced apply request
• prepare the required 0.2.14 changelog and release metadata

Triage

A clean CronJob updates correctly on current main. The reported stale state is reproducible when another field manager has claimed the generated container resource fields: changing KafkaBackup.spec.resources then returns four HTTP 409 apply conflicts, leaves status.observedGeneration behind, and keeps the old CronJob values. Deleting the CronJob clears that ownership, which explains the reported workaround.

Because the CronJob is generated in full and owned by the KafkaBackup, reconciliation now force-applies its desired fields. In the same Kind scenario, the fixed operator takes ownership, updates all resource requests and limits, and advances the observed generation without deleting the CronJob.

Verification

• bash scripts/release-gate.sh
• cargo fmt --all -- --check
• cargo check --all-targets
• cargo test --all-features (92 tests)
• cargo clippy --all-targets --all-features -- -D warnings
• CRD regeneration and checked-in CRD parity
• helm lint and default chart render
• release container build plus linkage/executable smoke test
• end-to-end reproduction and recovery on a disposable Kubernetes 1.36 Kind cluster

Fixes #41