fix(webhook): propagate GetResourceIfExist errors in validation webhooks (#373)

[Elvand-Lie]

Description

Seven call sites across three webhook validation files discard the error return from util.GetResourceIfExist using the pattern exist, _ := util.GetResourceIfExist(...). When the API server is temporarily unreachable, GetResourceIfExist returns (false, err). The discarded error causes the webhook to misinterpret an API failure as 'resource not found' and return a misleading validation error (e.g., 'cluster must be applied on project namespace' when the namespace exists but couldn't be looked up).

Changes:

• service/cluster_webhook_validation.go: Check error from GetResourceIfExist in validateAppliedInProjectNamespace and return field.InternalError
• service/service_export_config_webhook_validation.go: Check errors from all 5 GetResourceIfExist calls in validateServiceExportClusterAndSlice, validateServiceEndpoint, and validateServiceExportConfigNamespace
• service/slice_qos_config_webhook_validation.go: Check error from GetResourceIfExist in validateSliceQosConfigAppliedInProjectNamespace and add fmt import

All 7 sites now return field.InternalError with a descriptive message when the API lookup fails, consistent with how vpn_key_rotation_webhook_validation.go already handles errors.

Fixes #373

How Has This Been Tested?

• go build ./... passes
• Manual code review: all 7 error paths now return clear internal errors instead of misleading validation errors

Checklist:

• The title of the PR states what changed and the related issues number (used for the release note).
• Does this PR requires documentation updates?
• I've updated documentation as required by this PR.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have tested it for all user roles.
• I have added all the required unit test cases.

Does this PR introduce a breaking change for other components like worker-operator?

No. This only affects webhook validation error reporting. No APIs, CRDs, or external interfaces are changed. The behavioral change is that API lookup failures now return accurate internal errors instead of misleading validation errors.