Fix CanonicalTypeProvider to respect CodeGenMember when categorizing redefined properties

[Copilot]

When a property is renamed via [CodeGenMember] and the original name is redefined as a new custom property, CanonicalTypeProvider.BuildProperties() incorrectly categorized the redefined property as a spec property — causing it to silently disappear from the canonical view. The root cause: the property categorization loop at lines 160-171 checked _specPropertiesMap directly without consulting _renamedProperties, unlike the existing TryGetSpecProperty() method which already had this guard.

Changes

• CanonicalTypeProvider.cs: Aligned the custom property categorization logic with TryGetSpecProperty() — properties matching a spec name are now checked against _renamedProperties/_renamedFields before being treated as spec properties. Redefined properties without [CodeGenMember] are correctly routed to nonSpecProperties.

• ModelCustomizationTests.cs: Updated CanChangePropertyNameAndRedefineOriginal to assert the redefined property now appears in the canonical view (without WireInfo, as expected for a non-spec property).

• XmlSerializationCustomizationTests.cs: Added CanChangePropertyNameAndRedefineOriginal test covering the XML serialization path — validates that the [CodeGenMember] property is used for serialization/deserialization, not the redefined wrapper.

Example scenario

public partial class ShareAccessPolicy
{
    [CodeGenMember("Start")]
    public DateTimeOffset? PolicyStartsOn { get; set; }  // ← should be used for serialization

    public DateTimeOffset StartsOn { get; set; }          // ← wrapper, should NOT be serialized
}

Before: StartsOn could incorrectly steal the spec property mapping from PolicyStartsOn.
After: PolicyStartsOn is always preferred; StartsOn is treated as a non-spec custom property.