YAML provider returns null for a document containing any property the target type lacks, so removing a property orphans every saved YAML record #88

What's wrong

YamlSerializationProvider builds its deserializer without IgnoreUnmatchedProperties() (Essentials.SerializationProviders.Yaml/YamlSerializationProvider.cs:22-25):

private readonly IDeserializer deserializer = new DeserializerBuilder()
    .WithNamingConvention(CamelCaseNamingConvention.Instance)
    .Build();

YamlDotNet throws YamlException ("Property 'x' not found on type ...") for any mapping key that has no matching member. Deserialize<T> catches that exception at L81-L84 and returns default. The two JSON providers accept the same document and ignore the extra member, so ISerializationProvider behaves differently depending on the implementation behind it.

Failure scenario

Serialize V1 { Value = 42, Legacy = "x" }, then deserialize the result as V2 { Value }, i.e. the same type after Legacy was removed:

Removing or renaming a property is ordinary schema evolution. With YAML-backed persistence, every record written before that change now reads back as missing. The caller gets no error, because the exception is swallowed. Combined with RetrieveOrCreateAsync, the file is then overwritten with new T() (#82), so the user's other settings are destroyed too. #82 covers the overwrite. This issue covers why a well-formed, valid document is treated as unreadable in the first place.

Suggested fix

Add .IgnoreUnmatchedProperties() to the DeserializerBuilder, matching the JSON providers' default.

Acceptance criteria

• A test: a YAML document with an extra key deserializes into the narrower type with the known members populated.
• A contract test across all ISerializationProvider implementations asserts that unknown members are ignored. TOML can be included once TOML provider loses multi-word properties, lists and nested objects on a round trip, and throws MissingMethodException for records #69 is resolved, or noted if it differs.

Generated by Claude Code