fix(#2098): correct the LgoS and MCML CMM enum values to the registered signatures

[colourbill-ctrl]

Addresses the two enums reported in #2098, plus a third instance of the same
class found alongside them.

The defect

enum	was	registry	decoded
icSigLogoSync	0x44676F53	0x4C676F53	DgoS -> LgoS (GretagMacbeth)
icSigKonicaMinolta	0x4D434D44	0x4D434D4C	MCMD -> MCML (Konica Minolta)

Confirming @xsscx's RCA: both consumers key on the enum name -- the allow-list
in CIccProfile::CheckHeader (IccProfile.cpp:1972,1978) and the name table in
CIccInfo::GetCmmSigName (IccUtil.cpp:2053,2071) -- so a wrong value is wrong
in both directions at once. A profile whose preferred-CMM field held the
correctly registered LgoS was reported

LgoS: Unregistered CMM signature.

while a profile holding the unregistered DgoS validated clean and was given
LogoSync's name. Re-verified against registry.color.org/cmm-signatures on
2026-08-11.

The MCML line also carried an inline question -- "actually this is 'MCMD' -
which is right? Sent email to Dr. Phil Green." The live registry answers it, so
the comment is now the plain registered form like every other row.

Precedent for which side to fix

This is the same defect and the same remedy as icSigRefIccMAX, which carried
0x52494343 (RICC) against a comment and registry saying RIMX until #1473
corrected the value and kept the comment. That is recorded as delta B3 in
Tools/CmdLine/IccPawgReport/registry/PERMISSIVENESS_DELTAS.md. The registry
string is authoritative; the hex is what drifted. This PR adds a B5 section
recording these two -- that file states it flags every place the IccProfLib
signature tables diverge from the public registries, so landing two more
instances of a class it already tracks without a row would leave the governance
record understating the delta history.

Third instance: icSigVivo

Found by the same sweep, needs no value change -- 0x7669766F is correct -- but
its comment said 'VIVO', corrected to 'vivo'. Pinned in both directions
anyway, because it is the likeliest of the three to be "corrected" the wrong way:
the manufacturer registry lists Vivo as VIVO = 0x5649564F, and reconciling
the CMM enum against that row would reintroduce exactly the defect this PR
removes. Different registry, different header field -- they do not conflict.

How these were found

Decoded every 0x-literal signature enum in icProfileHeader.h and compared it
with its own quoted comment: 437 enums, four disagreements. Three are fixed
here. The fourth, icSigDigitalCinemaProjector (icProfileHeader.h:531), turned
out not to be an iccDEV defect and is deliberately excluded -- filed as
#2101. ICC.1-2022-05 itself gives that row as 'dcpj' with hex 64636A70h,
which decodes to dcjp; iccDEV faithfully carries the spec's hex. Extracting all
78 signature/hex pairs from the published ICC.1 PDF shows that row is the only
self-inconsistent one in the table (ICC.2-2023: 49 rows, 0 inconsistent), so it
needs an ICC editorial decision, not an implementation choosing a column.

Test

Extends the existing iccdev.cmm-registry-allowlist rather than adding a CTest,
so the CMake wiring is untouched (definition at Build/Cmake/Testing/CMakeLists.txt:547,
invoked from both call sites at :4423 and :4695).

The checks already in that file cannot catch this class -- they reach the
allow-list through enum names, and case icSigLogoSync: accepts whatever number
the header assigns, so they pass identically before and after. The new checks
drive it with literal registered hex, plus static_asserts on the constants:

• 0x4C676F53 / 0x4D434D4C must NOT warn -- red before this change.
• 0x44676F53 / 0x4D434D44 must STILL warn -- catches a fix that adds the
  registered value while leaving the typo accepted.
• 0x7669766F must NOT warn and 0x5649564F must warn -- keeps the CMM and
  manufacturer registries distinguishable at the allow-list.

Verification

• Red/green measured, not asserted. Reverting only icProfileHeader.h fails
  the build on the static_asserts; with those removed it fails 4 of 12
  runtime checks. With the change applied, 12/12 pass.
• clang 18 and gcc Release, zero warnings.
• ctest 174/175; the single failure is iccdev.spectral-tiff-preview, the
  known local python imagecodecs gap, unrelated to this change.
• No corpus impact: all 105 tracked .icc/.icm profiles were scanned and
  none carry any of the four values; no tracked XML or JSON references them
  either. That is also why no round-trip could ever have caught this.

Part of #2098

[xsscx]

2026-08-11 10:14:43 UTC