Fix invalid inherited color scheme fallback

[RohithPariki]

Summary

Fixes the fallback behavior when an invalid color scheme name is inherited from a fragment parent.

References

Fixes #20462

Detailed Description

When _validateAllSchemesExist() encounters an invalid color scheme reference, it clears locally defined values so the appearance falls back to the default color scheme.

However, ClearDarkColorSchemeName() and ClearLightColorSchemeName() only clear values stored on the leaf AppearanceConfig. If the invalid color scheme is inherited from a fragment parent, clearing the leaf is a no-op because the leaf does not own the value, allowing the invalid inherited value to continue resolving.

This change preserves the existing behavior for locally defined values while handling inherited values separately. If the invalid color scheme is inherited, the leaf profile is assigned the default color scheme so the invalid inherited value no longer resolves during validation.

This change only affects the fallback behavior described in #20462 and does not modify warning classification.

Validation

• Added a regression test covering an invalid color scheme inherited from a fragment using SettingsLoader.
• Verified that inherited invalid color schemes resolve to the default color scheme after validation.

Checklist

• Fixes Clear{Dark,Light}ColorSchemeName() does not clear a value inherited from a fragment parent #20462

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.