Update fleetautoscalers.go

[MusGaas]

/kind bug

What this PR does / Why we need it:
applyWebhookPolicy and applyWasmPolicy both dereference Response.Scale
without checking if Response is nil. When a webhook or Wasm policy
returns a JSON body that omits the response field (e.g., {}),
json.Unmarshal succeeds with Response as a nil pointer. The subsequent
dereference panics, crashing both HA controller replicas via the shared
workqueue and halting cluster-wide FleetAutoscaler reconciliation until
an admin removes the resource.

Both sites now return an explicit error when Response is nil, allowing
the reconcile loop to handle the error gracefully rather than panicking.

Tested against helm install agones release 1.57.0 in a kind cluster.
Both controller pods entered CrashLoopBackOff before the fix. After
the fix, the error is returned cleanly with no panic.

Which issue(s) this PR fixes:
Closes #4555

Special notes for your reviewer:
This fix was identified and reported via Google's OSS VRP (Agones
documented security intake at g.co/vulnz). Two sites fixed in the
same file — applyWebhookPolicy and applyWasmPolicy — same root cause,
same one-line nil check pattern.

[MusGaas]

Hi, could a maintainer please run /gcbrun to trigger the CI build? Thank you.

[markmandel]

We should add a unit test for this, to make sure it continues to not be a problem.

[markmandel]

This fix was identified and reported via Google's OSS VRP (Agones
documented security intake at g.co/vulnz). Two sites fixed in the
same file — applyWebhookPolicy and applyWasmPolicy — same root cause,
same one-line nil check pattern.

Two things:

1. That's not our security policy anymore, and hasn't been for several weeks.
2. I don't think this is a security issue, since it's not something that is accessible from the outside world (unless someone configures their cluster badly - which we can't control). Unless I'm missing something here?