fix(api): nil pointer panic when Helm chart has no liveness probe

[A386official]

Bug

When deploying a Helm chart application that has a readiness probe but no liveness probe configured, the API panics with a nil pointer dereference at resource_public_function.go:332, returning no useful error to the user. This was reported in #2512 with a full stack trace.

Root Cause

In PodTemplateSpecResource(), the readiness probe handling block (the else branch, entered when livenessProbe == nil) contains a copy-paste bug on line 332:

// Inside the else block — livenessProbe is nil here
readinessProbe := parameter.Template.Spec.Containers[0].ReadinessProbe
if readinessProbe != nil {
    if readinessProbe.HTTPGet != nil {
        // ...
        hcm.Port = int(readinessProbe.HTTPGet.Port.IntVal)
        if hcm.Port == 0 {
            // BUG: references livenessProbe, which is nil in this branch
            hcm.Port = int(NameAndPort[livenessProbe.HTTPGet.Port.StrVal])
        }
    }
}

The named-port fallback lookup incorrectly references livenessProbe.HTTPGet.Port.StrVal instead of readinessProbe.HTTPGet.Port.StrVal. Since livenessProbe is guaranteed to be nil in the else branch, dereferencing it causes a panic.

Fix

Change livenessProbe to readinessProbe on the affected line, matching the surrounding code's intent:

-    hcm.Port = int(NameAndPort[livenessProbe.HTTPGet.Port.StrVal])
+    hcm.Port = int(NameAndPort[readinessProbe.HTTPGet.Port.StrVal])

This is a one-line, surgical fix that corrects the variable reference to match the enclosing scope. No behavior change for the liveness probe path.

Closes #2512