fix: stop requeueing ApisixConsumer forever after a successful delete

[alliasgher]

Type of change:

• Bugfix

What this PR does / why we need it:

Fixes #2849

When an ApisixConsumer is deleted, Reconcile gets a NotFound from the cache, synthesizes a minimal object and calls Provider.Delete. On the success path there is no return, so execution falls out of the IsNotFound block to the trailing return ctrl.Result{}, err, which hands back the captured NotFound error. controller-runtime sees a non-nil error, so it requeues the key indefinitely with exponential backoff even though the delete already succeeded. That matches the increasing intervals in the report.

The fix is to return after a successful delete, which is what every other reconciler already does.

The issue asks whether other controllers have the same problem. I checked all of them: there are 15 Provider.Delete call sites across 13 files in internal/controller, and every one is followed by return ctrl.Result{}, nil except apisixconsumer_controller.go. So this is the only affected reconciler and no wider change is needed.

Pre-submission checklist:

• Did you explain what problem does this PR solve? Or what new features have been added?
• Have you added corresponding test cases?
• Have you modified the corresponding document? (no user-facing behaviour or API change, so no doc update)
• Is this PR backward compatible?

Tests

internal/controller/apisixconsumer_controller_test.go adds three cases:

• TestApisixConsumerReconcile_DeletedObjectDoesNotRequeue is the regression guard. It asserts the reconcile succeeds, returns an empty ctrl.Result, and that the provider received the right key. With only the two production lines reverted it fails with apisixconsumers.apisix.apache.org "gone" not found, so it is not vacuous.
• TestApisixConsumerReconcile_DeleteErrorIsReturned proves a provider failure still propagates rather than being swallowed.
• TestApisixConsumerReconcile_NonNotFoundGetErrorIsReturned uses interceptor.Funcs to return an internal error from Get and asserts it is returned and does not trigger a spurious provider delete.

Verified locally:

• go build ./... clean
• go test $(go list ./... | grep -v '/test/') -count=1 all pass
• go vet ./internal/controller/ and gofmt -l clean
• golangci-lint run ./internal/controller/... reports no issues in the changed files

I did not run the envtest-backed make test or the e2e and conformance suites. This change touches no CRD, manifest, or API surface.