Fix MutateOrNew updates with required primary keys

[bazer]

Summary

• validate required primary-key arguments against the existing row's authoritative canonical key
• avoid tracking validated primary-key values as mutable assignments while continuing to apply required non-key values
• preserve missing-row inserts and reject genuinely different keys before provider execution
• add generator coverage for composite, GUID, scalar-converted/typed, and binary keys plus cross-provider compliance coverage

Verification

• run --plan quick --output failures (2,425/2,425 passed)
• focused EmployeesMutationTests/Mutation_MutateOrNew* on SQLite file and in-memory targets (15/15 passed across runs)
• latest MySQL/MariaDB attempt was blocked by the local Podman socket being unavailable before provider execution
• git diff --check

Closes #112

[bazer]

Reviewed commit 099d17c against master at 7a4caaa. No actionable findings. The generated existing-row path validates every supplied required primary-key component against the immutable row's cached canonical key, avoids recording primary-key assignments, and still applies required non-key assignments. The comparison uses KeyFactory.CreateKeyFromModelValue and DataLinqKey, so scalar converters, enums, and binary structural equality share DataLinq's established normalization; the missing-row insert path and callback overload retain their prior behavior. Independent verification: the quick plan passed 2,425/2,425 cases (66 generator, 1,716 unit, 141 memory, 502 SQLite-file compliance), git diff --check is clean, and all 11 required GitHub checks are green, including MySQL 9.7 and MariaDB 12.3 compliance. Residual risk is low: GUID, typed/scalar-converted, and binary key call sites are compile-verified and their canonicalization primitives are covered by the unit suite, while the new end-to-end mutation cases exercise scalar and composite keys across the provider matrix.