fix: sync SliceDisplayName on every reconcile in updateSliceConfig

[mdryaan]

Description

updateSliceConfig in pkg/hub/controllers/slice_controller.go only set SliceDisplayName inside the if meshSlice.Status.SliceConfig == nil block populated once at first creation and never updated again. If the display name changed in the hub WorkerSliceConfig, the worker cluster's Slice.Status.SliceConfig.SliceDisplayName would hold the stale value indefinitely with no way to reconcile it short of deleting and recreating the slice.

All other runtime-mutable fields (QoS profile, namespace isolation, gateway service type, external gateway config, etc.) are already synced unconditionally on every reconcile. SliceDisplayName was simply missed. SliceType is intentionally left inside the nil guard — it is immutable after slice creation and that behaviour is unchanged.

Fix adds one unconditional assignment after the nil guard, mirroring exactly how SliceGatewayServiceType is handled in the same function.

Fixes #493

How Has This Been Tested?

Added TestUpdateSliceConfigDisplayNameUpdatedOnSubsequentReconcile to pkg/hub/controllers/slice_controller_unit_test.go. The test constructs a Slice with SliceConfig already non-nil (simulating a subsequent reconcile after initial creation) and a stale SliceDisplayName, calls updateSliceConfig with an updated hub config, and asserts the field is overwritten with the new value.

• TestUpdateSliceConfigDisplayNameUpdatedOnSubsequentReconcile — passes
• make fmt — no formatting changes
• make vet — no issues
• make build — builds cleanly
• make test — all suites pass; pre-existing spoke timeout failures confirmed identical on master

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 ran go fmt
• I have updated the helm chart 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.
• I have verified the E2E test cases with new code changes.
• I have added all the required E2E test cases.

Does this PR introduce a breaking change?