Warn that an incomplete color scheme is incomplete, not missing (#11457)

[drvoss]

Summary of the Pull Request

Color schemes that are missing some of their colors are rejected during parsing and
dropped. A profile that references such a scheme then produces the UnknownColorScheme
warning ("...the value matches the name of a color scheme..."), which misleads the user
into thinking the scheme name is wrong when the scheme actually exists but is incomplete.
This adds a distinct IncompleteColorScheme warning so the message is accurate.

References that come from a layer the user cannot edit (fragments, dynamic profile
generators, defaults.json) are suppressed instead of warned, since a broken built-in
reference would otherwise be inescapable for the user.

References and Relevant Issues

Closes #11457. Related: #11456 (added magenta/brightMagenta aliases; note the
original repro no longer reproduces because of it — a genuinely missing color such as
cyan is needed).

Detailed Description of the Pull Request / Additional comments

• ColorScheme::FromJson only fails when a scheme has no name or fewer than 16 colors.
  When it returns null but the JSON has a non-empty name, the scheme exists but is
  incomplete. SettingsLoader now collects those names (both user and fragment parse
  paths) into incompleteColorSchemes.
• CascadiaSettings::_validateAllSchemesExist raises IncompleteColorScheme when a
  profile references a name in that set, and UnknownColorScheme (as before) otherwise.
• ColorScheme parsing/merging/serialization is intentionally not modified, so scheme
  layering and round-tripping are unchanged; incomplete schemes are still ignored.
• New warning added at the end of the SettingsLoadWarnings enum (existing ordinals
  unchanged) with an en-US resource string.
• Known limitation: if a complete scheme of the same name also exists (e.g. the in-box
  copy), an incomplete override is silently ignored without a warning — unchanged from
  today. A scheme that reaches 16 colors via duplicate aliases while omitting a real slot
  is likewise not flagged (pre-existing ColorScheme counting behavior, out of scope).
• References from fragments/generators/defaults.json are suppressed via
  _originOfColorSchemeName(), which walks the profile's inheritance graph to find which
  layer actually set the colorScheme value (fragment-contributed profiles don't appear
  in _allProfiles on their own — SettingsLoader::_addUserProfileParent() merges them
  into a user-owned child, so Origin() alone can't distinguish "fragment set this" from
  "user set this").
• Follow-up fix (leaf-vs-parent origin misattribution): the initial version of
  _originOfColorSchemeName() used only the public <NAME>OverrideSource() accessor,
  which walks parents but never inspects the leaf itself. When both the leaf (the
  user's own settings.json) and a parent (e.g. an in-box profile) set colorScheme,
  the effective value is the leaf's — but OverrideSource() still returned the parent,
  so the user's own typo was misattributed to the in-box layer and silently swallowed.
  This is a realistic scenario: defaults.json sets colorScheme directly on the
  Windows PowerShell and Command Prompt profiles, so any user who overrides colorScheme
  on those same (GUID-matched) profiles hits this path. Fixed by checking Has<NAME>()
  first: if the leaf set its own value, origin is attributed to the leaf regardless of
  what any parent has; the walked-parent OverrideSource() is only consulted when the
  leaf itself is silent. Added a regression test
  (UserOverrideOfInboxColorSchemeTypoWarns) that reproduces this via matching profile
  GUIDs.

Validation Steps Performed

• Added DeserializationTests::TestIncompleteColorSchemeName (user settings path) and
  ColorSchemeTests::IncompleteColorSchemeInFragmentWarns (fragment path).
• Added ColorSchemeTests::BrokenSchemeReferencedByFragmentProfileIsSilent (fragment /
  in-box references are suppressed, not warned) and
  ColorSchemeTests::UserOverrideOfInboxColorSchemeTypoWarns (regression test for the
  leaf-vs-parent origin bug described above).
• TestInvalidColorSchemeName (genuinely missing name → UnknownColorScheme) still passes.
• Full SettingsModel.Unit.Tests suite: 161/161 passing locally.
• clang-format (22.1.3, same binary as CI) run over all touched files with no diff.

PR Checklist

• Closes "Incomplete" color schemes are rejected as if they don't exist (possibly only if in fragment) #11457
• Tests added/passed
• Documentation updated — N/A (no user-facing docs/schema change)
• Schema updated — N/A

How the origin of a broken reference is determined

A broken color-scheme reference now produces a warning only when the reference
originates from a layer the user can edit (User or ProfilesDefaults). References that
originate from a fragment, a dynamic profile generator, or defaults.json are suppressed,
so a broken reference the user cannot remove never surfaces an inescapable warning
(per @DHowett's note in #11457).

Origin is resolved by a file-local helper, _originOfColorSchemeName() in
CascadiaSettings.cpp -- not from profile.Origin(). Fragment-contributed profiles
are merged into a user-owned child profile and stamped OriginTag::User, so the
profile's own origin would misattribute the reference to the user. The helper instead
walks the inheritance graph, checking the leaf (Has*ColorSchemeName()) before trusting
*ColorSchemeNameOverrideSource() (which only inspects parents). _noteMissingColorScheme()
applies the User/ProfilesDefaults allow-list.

Note: a scheme defined by a fragment but referenced by the user is still warned --
only fragment-originated references are suppressed.

Known limitation (out of scope): inbox defaults.json and user profiles.defaults share the
ProfilesDefaults origin tag, so both are treated as user-actionable.

Split out separately: #20462 (Clear*ColorSchemeName does not clear fragment-inherited values).

[DHowett]

Thanks! I'm thinking about this a bit.

Even though #11457 mentions fragments, I think it is very important that Terminal not display errors for Fragment JSON files. They can be installed in locations that the user cannot write to, a broken Fragment file in a system folder will cause a warning message the user can never escape from.

[drvoss]

Thanks for taking a look — you're right, and digging into it I found the problem is a bit deeper than the PR as written.

First, a correction to my own PR: suppressing the fragment-origin collection isn't sufficient. _validateAllSchemesExist() is a two-way branch with no "stay silent" path, so dropping fragment names from the incomplete set just downgrades IncompleteColorScheme back to UnknownColorScheme -- the dialog still appears, only with worse wording.

Second, and more importantly: this inescapable warning already exists on main. A fragment-provided profile that references a scheme the same fragment failed to define produces UnknownColorScheme in shipping Terminal today; _validateAllSchemesExist() has never filtered by origin. This PR didn't introduce the dialog, it only re-worded it.

So I'd like to fix the underlying issue properly, following the precedent already set by _resolveSingleMediaResource(), which ignores Fragment-origin failures and only flags User/ProfilesDefaults ones.

The key refinement is what we key the suppression on. I think it should be the origin of the layer that actually set the colorScheme value, not the origin of the file that defined the broken scheme:

Reference set by	Scheme defined in	Warn?
user settings.json	user settings.json	yes -- IncompleteColorScheme
user settings.json	a fragment	yes -- the user can edit their own reference
a fragment profile	a fragment	no -- inescapable
a fragment profile	nowhere	no -- inescapable (fixes the existing bug)

Note the second row is the original #11457 repro, so it needs to keep warning.

One trap worth calling out: profile.Origin() can't be used for this. _addUserProfileParent() merges fragment profiles into a user-owned child, and FinalizeLayering() stamps that child OriginTag::User; Origin is a plain WINRT_PROPERTY, so it isn't inherited from the fragment parent. I resolve the origin through DarkColorSchemeNameOverrideSource() -> SourceProfile() -> Origin() instead, which is the same inheritance-graph walk ResolveMediaResources() uses for icons.

I've pushed that, along with a regression test that asserts zero warnings for a fragment-authored profile pointing at a broken scheme (it fails both on main and on the previous revision of this PR).

Separately: ClearDarkColorSchemeName() only clears the leaf's own value, so when the bad name came from a fragment parent the clear is a no-op and the profile keeps a dangling scheme name. That's pre-existing and orthogonal -- happy to file it separately rather than grow this PR.

[drvoss]

@DHowett -- following up on your concern that fragment-referenced schemes must never warn. The revision addresses it directly.

Root cause. _validateAllSchemesExist() never distinguished who set a broken color-scheme reference, so a scheme contributed by a fragment could surface a warning the user has no way to remove.

What changed.

• A file-local helper, _originOfColorSchemeName(), walks the appearance's inheritance graph to find the layer that actually supplied the effective scheme name. It deliberately does not use profile.Origin(): fragment-contributed profiles are merged into a user-owned child and stamped OriginTag::User, so the profile's own origin would misattribute the reference. The helper checks the leaf first (Has*ColorSchemeName()) before trusting *ColorSchemeNameOverrideSource(), which only walks parents.
• _noteMissingColorScheme() then records a warning only when that resolved origin is User or ProfilesDefaults. References originating from a fragment, a dynamic profile generator, or defaults.json are suppressed -- a broken reference the user cannot edit never produces an inescapable warning.
• A scheme defined by a fragment but referenced by the user is still warned, which I believe matches the intent.

Tests. ColorSchemeTests.cpp adds IncompleteFragmentSchemeReferencedByUserWarns, BrokenSchemeReferencedByFragmentProfileIsSilent, and UserOverrideOfInboxColorSchemeTypoWarns (the last is a leaf-vs-parent regression guard); DeserializationTests.cpp adds TestIncompleteColorSchemeName. Because a string colorScheme sets both the dark and light names, these tests already exercise both origin branches, and UnfocusedAppearance runs through the same helper -- so no origin branch is left untested.

Known limitation, out of scope here. Inbox defaults.json and user profiles.defaults share the ProfilesDefaults origin tag, so the allow-list treats both as user-actionable. Narrowing that is independent of this change.

I've also split the separate Clear*ColorSchemeName fragment-inheritance bug out into #20462 to keep this PR scoped to the warning classification. Happy to add coverage for any specific origin case you'd like to see spelled out.

[drvoss]

Pushed a small follow-up cleanup that moves effective color-scheme origin resolution into AppearanceConfig, reusing its leaf-first inheritance logic. There is no intended behavior change; clang-format 22.1.3 passes, and the relevant Settings Model tests pass locally (ColorSchemeTests: 10/10; TestIncompleteColorSchemeName: 1/1).