[Bug] StatefulSet analyzer ignores non-zero start ordinals

Expected Behavior

The StatefulSet analyzer should inspect the Pods in the ordinal range defined by the StatefulSet: [spec.ordinals.start, spec.ordinals.start + spec.replicas). When spec.ordinals is omitted, the start ordinal should remain 0.

For a StatefulSet with start: 1 and replicas: 2, the analyzer should inspect database-1 and database-2, and report a failure when either Pod is not running.

Current Behavior

StatefulSetAnalyzer always starts its Pod lookup at ordinal 0 and loops through 0..spec.replicas-1. It therefore looks for database-0 even when the controller created the valid Pod range database-1 and database-2.

If database-0 does not exist, the analyzer breaks out before checking the real StatefulSet Pods. A Pending or otherwise unhealthy database-1 can consequently produce no StatefulSet result. The same zero-based assumption also prevents the existing first-missing-Pod Event fallback from running when the configured first ordinal is non-zero.

Steps to Reproduce

1. On a Kubernetes cluster where StatefulSet start ordinals are available, create a StatefulSet with a non-zero start ordinal:

   yaml复制

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: database
     namespace: default
   spec:
     serviceName: database
     replicas: 2
     podManagementPolicy: Parallel
     ordinals:
       start: 1
     selector:
       matchLabels:
         app: database
     template:
       metadata:
         labels:
           app: database
       spec:
         containers:
         - name: database
           image: nginx

2. During reconciliation, make database-1 remain Pending while database-2 is Running. The StatefulSet status will reflect fewer available replicas, for example availableReplicas: 1.

3. Run k8sgpt analyze --filter StatefulSet.

4. Observe that the current analyzer produces no StatefulSet result because it first requests the non-existent database-0 and stops. The expected result identifies database-1 as not running.

The same behavior is reproduced deterministically with the repository fake client using a StatefulSet with replicas: 2, spec.ordinals.start: 1, database-1 Pending, database-2 Running, and status.availableReplicas: 1: the baseline at origin/main (05247a8) returns zero results.

Environment

• k8sgpt version: main (05247a851ba9292ca57e5070f1d0c4d3986b8d4c)
• Kubernetes version: 1.31+ for the stable StatefulSet start ordinal feature
• AI Backend/Provider: n/a; the defect occurs before AI explanation
• OS/Platform: macOS / client-go fake client

Additional Context

Kubernetes defines StatefulSet Pod identity by ordinal. The optional spec.ordinals.start field changes the first ordinal, and the assigned range is [spec.ordinals.start, spec.ordinals.start + spec.replicas). The current source in pkg/analyzer/statefulset.go does not read spec.ordinals.

References:

• https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#start-ordinal
• https://kubernetes.io/docs/reference/kubernetes-api/apps/stateful-set-v1/

A focused fix should derive a default-zero start ordinal from spec.ordinals.start, use it for the Pod lookup range, and use it when deciding whether to fetch the first-missing-Pod Event. This issue does not change StatefulSet status semantics, service validation, Event matching, or other analyzers.

The regression test covers both a non-zero ordinal Pod that is not running and a missing first non-zero ordinal with a StatefulSet Warning Event. On the isolated candidate worktree, the fix passes the focused test, all StatefulSet analyzer tests, go test ./... -count=1, go vet ./pkg/analyzer/, go vet ./..., gofmt, and git diff --check.

No matching open Issue or PR was found for StatefulSet start ordinals, spec.ordinals, StatefulSetStartOrdinal, or this analyzer behavior. Closed #1249 / PR #1256 concern retrieving StatefulSet Events, not the configured ordinal range.

I am willing to submit a focused PR after maintainer confirmation.