Setting a material's shader to a copy if it has HDR colors can cause those colors to be incorrectly converted

Noticed with copies of the TextMeshPro/Distance Field shaders.
 
Original post: https://unity.slack.com/archives/C06TQ82JY/p1680093001453539
 
The case this was seen in:

1. At boot an instance of the shader and default property sheet get created.
2. The color properties are defaulted to low-range and all have m_Flags values of 0, so "_FaceColor" (the problem property) ends up with its m_Descs flag with kMaskSRGB set.
3. An instance of this shader (and a material) is now loaded from an asset bundle. m_Flags in this case is set to 16 (kPropFlagHDR), as the _FaceColor value is high-range. m_Descs does not end up with kMaskSRGB set.
4. A script 'corrects' the shader of the material to what is the embedded version of the shader. From the script's perspective this doesn't seem it should be an issue since they share the same properties anyway.
5. The shader set calls BuildProperties which does a{{ ShaderPropertySheet::CopyFrom}} using the 'default' copy of the shader's property sheet, including the{{ m_Descs}} state which means kMaskSRGB ends up set, as if the properties aren't going to now have the serialized values dropped in.
6. AssignDefinedPropertiesTo copies in the high-range colour values which are not recognized as high-range because of m_Descs's state having been changed, so the values get incorrectly converted.

The precursor to this happening appears to be having the in-project version of the shader somehow serialized with m_Flags values serialized as 0 for the HDR properties.