fix: use tcp startup probes for tls-backed workloads

[immanuwell]

Fixes #1824

When a managed app enables TLS on its HTTP endpoint, the operator still renders default httpGet app probes. kubelet hits that endpoint without a TLS handshake, so health checks can fail even when the pod is fine.

This keeps plain HTTP behavior as-is, and switches the default app probe to a tcpSocket startupProbe only for TLS-backed endpoints when no custom probes are set. Custom probes still win, no funny business.

Repro:

1. Create a VMAuth with spec.extraArgs.tls: "true" and no custom probes.
2. Check the rendered pod spec. It gets default httpGet probes on the app port.
3. Run it with TLS or mTLS. kubelet probe requests fail, pod looks sick for no good reason.

Checks:

• go test ./internal/controller/operator/factory/...
• make test

[cubic-dev-ai]

No issues found across 4 files

_{Re-trigger cubic}

[AndrewChubatiuk]

@immanuwell @vrutkovs
why tcp liveness and readiness checks are not used for TLS endpoints by default?
why they are just disabled?

[immanuwell]

@AndrewChubatiuk I didn't switch TLS endpoints to default TCP livenessProbe/readinessProbe because, per the discussion in #1824 these probes only verify that the listener is accepting connections, not that the app is actually healthy or meaningfully ready

so the agreed direction was to use a TCP startupProbe for the default TLS/mTLS case, and not keep steady-state default liveness/readiness checks with weaker semantics

custom probes still override this, so users who want TCP liveness/readiness can set them explicitly

that's my understanding of the agreed direction, maybe I'm wrong

[AndrewChubatiuk]

LGTM! Thanks for contribution!