fix: add listMapKey to VMRule rules for structured server-side apply merge

[mvanhorn]

Summary

Adds a +listMapKey=alert marker to the VMRule rules array so Kubernetes server-side apply merges rule entries by key instead of replacing the whole list, preventing rules from clobbering each other on partial applies.

Why this matters

VMRule.spec.groups[].rules was a plain list with no listMapKey, so a server-side apply that touched one rule replaced the entire rules array, dropping rules managed by other appliers (#657). Marking the list with its identifying key lets the API server do a structured merge. The change is in api/operator/v1beta1/vmrule_types.go with the regenerated CRD in config/crd/overlay/crd.yaml, plus a unit test and docs/api.md / docs/CHANGELOG.md updates.

Testing

• Added a unit test asserting the merge-key marker is present on the rules field.
• go build and go vet pass on the api module; the CRD overlay regenerates cleanly.

Closes #657

---

Summary by cubic

Make VMRule.spec.groups[].rules a map-style list keyed by record and alert so server-side apply merges rules by key instead of replacing the list. Adds XOR validation and defaults for record/alert to prevent invalid specs and rule clobbering (fixes #657).

• Bug Fixes
  • Marked RuleGroup.rules with +listType=map, +listMapKey=record, +listMapKey=alert; set Rule.record/Rule.alert defaults to ""; regenerated CRDs with x-kubernetes-list-type, x-kubernetes-list-map-keys, and defaults; updated docs/api.md and docs/CHANGELOG.md.
  • Enforced validation: error if both record and alert are set, or neither.
  • Added tests for CRD schema markers and JSON field names, JSON round-trip/validation, composite-key SSA merges for rules, and traditional SMP merge-by-name behavior for groups.

^{Written for commit 7d0ebe1. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 5 files

_{Re-trigger cubic}

[AndrewChubatiuk]

hey @mvanhorn
thanks for PR
could you clarify a purpose of added tests cases? they seem to be irrelevant