Expected-output aspect tests with AspectTesting on xunit.v3, inside the solution's test run #220

Goal

Test the aspects against expected output a reviewer can read, with Metalama.Testing.AspectTesting, inside the solution's test run. Needs #173.

The #93 spike (spikes/AspectTestingSpike) found that AspectTesting 2026.1 works, but only as a separate VSTest command. It depended on xunit v2, and a VSTest project in CodoMetis.TypeKit.slnx makes dotnet test --solution refuse the whole run. Metalama 2027.0 moves Metalama.Testing.AspectTesting and Metalama.Testing.UnitTesting to xunit.v3, and renames TestContext to MetalamaTestContext (release notes, "Breaking changes").

To measure

1. Does an AspectTesting project on 2027.0 run under Microsoft Testing Platform, beside the other projects, with dotnet test --solution and through tools/BuildVerdict?
2. Does it test the real src/CodoMetis.TypeKit.Generators (internal aspects, applied by the TransitiveProjectFabric) through a project reference?
3. Can its expected files and the README's generated-code blocks (GeneratedCodeBlockTests, Docs: show the generated code for the simple cases in the READMEs #92) share one source, or do they stay separate on purpose?

Done when

• If it runs in the solution: expected-output tests for a plain value object, a validated one and a closed set, run by CI, each shown failing on a seeded change to an aspect (verify-the-guard).
• If it doesn't: the spike README gets the 2027.0 answer, and the issue closes as not planned with the evidence.