VMCluster/VMAlertmanager: reject serviceSpec.type override with useAsDefault

[mehrdadbn9]

What

Follows up on #2487. As discussed in the issue, the default Service of vmselect, vmstorage and vmalertmanager is intentionally headless (clusterIP: None) because it also exposes cluster-native / gossip ports. Because of that, combining serviceSpec.useAsDefault: true with an explicit spec.type silently produces a service that is still headless - the user gets no error and no VIP, which is confusing.

Per the maintainer's suggestion in #2487 (comment) (prohibit overriding the service type for these components when useAsDefault: true), this PR makes the operator reject that combination with a clear error message instead of silently ignoring it.

Changes

• AdditionalServiceSpec.ValidateNoServiceTypeOverrideWithUseAsDefault(component) - new helper that rejects an explicit spec.type when useAsDefault is set.
• Wired into VMCluster.Validate() for vmselect and vmstorage.
• Wired into VMAlertmanager.Validate() for vmalertmanager.
• vminsert is intentionally left allowed: its default Service is not headless, so an explicit type override there works as expected.

Users who need a different service type can still create a separate additional Service by setting serviceSpec.useAsDefault: false with a distinct metadata.name.

Tests

Added unit test cases covering: reject for vmselect/vmstorage/vmalertmanager, allow when no explicit type is set, allow separate additional services, and allow type override for vminsert.

go build ./...          # OK
go vet ./operator/v1beta1/  # OK
go test ./operator/v1beta1/  # ok (full package)

Feedback welcome - happy to adjust the error message wording or the scope if you'd rather also cover vminsert.

[cubic-dev-ai]

All reported issues were addressed across 5 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>