fix: deadlock occurs when updating configuration fails

[AlinsRan]

Type of change:

• Bugfix
• New feature provided
• Improve performance
• Backport patches
• Documentation
• Refactor
• Chore
• CI/CD or Tests

What this PR does / why we need it:

Returning directly when an error occurs may result in the lock not being released.

apisix-ingress-controller/internal/adc/client/client.go

Lines 76 to 84 in 75d068a

	d.mu.Lock()
	deleteConfigs := d.ConfigManager.Update(args.Key, args.Configs)
	for _, config := range deleteConfigs {
	if err := d.Store.Delete(config.Name, args.ResourceTypes, args.Labels); err != nil {
	log.Errorw("failed to delete resources from store",
	zap.String("name", config.Name),
	zap.Error(err),
	)
	return err

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?
• Is this PR backward compatible? If it is not backward compatible, please discuss on the mailing list first

[Copilot]

Pull Request Overview

This PR fixes a deadlock issue in the Apache APISIX Ingress Controller by refactoring the client update methods to ensure proper mutex unlocking when errors occur. The change extracts the store operations into a separate method with proper defer unlock pattern.

• Refactored Update, Delete, UpdateConfig, and DeleteConfig methods to use a common pattern
• Introduced applyStoreChanges method with proper mutex handling using defer unlock
• Created StoreDelta struct to track applied and deleted configurations

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[ronething]

lgtm