fix(scaling): guard GetCurrentReplicas against nil ScaleTargetGVKR

[ggarb]

Problem

At ~10k ScaledObjects being created at 10/s, the KEDA operator panics:

panic: runtime error: invalid memory address or nil pointer dereference
pkg/scaling/resolver/scale_resolvers.go:731 GetCurrentReplicas
pkg/scaling/executor/scale_scaledobjects.go:44 RequestScale
pkg/scaling/scale_handler.go:282 checkScalers
pkg/scaling/scale_handler.go:199 startScaleLoop

Root cause is the same informer-cache race described in #4389 / tracked
in #4955: scaledObject.Status.ScaleTargetGVKR can be nil when the
scale loop first invokes GetCurrentReplicas. The existing code
dereferences .Group / .Kind on the nil pointer, crashing the whole
operator process and taking down every other scale loop with it.

ResolveScaleTargetPodSpec already defends against this race
(scale_resolvers.go L103-L119). GetCurrentReplicas does not.
This PR applies the same pattern.

Fix

If Status.ScaleTargetGVKR is nil on entry, re-fetch the ScaledObject
via the client. If it is still nil after re-fetch, return a descriptive
error instead of panicking.

Repro context

Observed during a 10k-ScaledObject KWOK load test at Netflix, after
raising --kube-api-qps/burst to eliminate client-go throttling
(previous 1k bottleneck). Once client-side throttling was gone, fast
ScaledObject creation widened the cache-race window enough that the
nil-pointer panic fired reliably before the 750th object was created.

Tests

• Added TestGetCurrentReplicas_NilScaleTargetGVKR with three cases:
  • nil on input, re-fetch succeeds with populated GVKR → returns
    correct replica count (Deployment path)
  • nil on input, re-fetch also returns nil → returns a descriptive
    "probably invalid ScaledObject cache" error
  • nil on input, re-fetch fails (SO missing) → returns fetch error
• All existing tests in ./pkg/scaling/... pass.

Fixes / refs

• Refs Constants crashes in keda operator after deploying service controlled by scaledobject #4389
• Refs ScaledObject no being cached correctly at all times #4955 (root-cause tracking issue; this PR adds another guard
  site, doesn't close the underlying race)
• Refs Keda Operator - invalid memory address or nil pointer dereference during large scaler failures #6176 (symptom-matching closed-stale issue)

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[JorTurFer]

Thanks for the fix!
As now it's starting to be in multiple places, does it make sense to extract that code into a funciton that we can reuse and implicitly tracks all the usages of this hack?