Remove migration-era "V2"/"Opt-in" framing from project READMEs

[tayzer]

Summary

16 project READMEs under Source/ and Tests/ still describe themselves in migration-era terms — "Opt-in ... for V2", "V2 services", "Must not reference V1 projects". The V1→V2 migration is complete: V1 is frozen under archive/v1-comparisontool/ and is not in the solution or built by CI. There is no V2 to distinguish from anything, and no V1 for a new project to accidentally reference.

Examples

Source/ParityBench.NET.Web/README.md:

Opt-in Blazor Server host for V2.

• Web composition root for V2 services.
• Must not reference V1 projects or duplicate UI/business logic from shared layers.

Source/ParityBench.NET.Cli/README.md:

Opt-in command-line host for V2 request comparison.

• CLI composition root for V2 services.

Source/ParityBench.NET.Desktop/README.md, Source/ParityBench.NET.Report/README.md, and most of the Tests/* READMEs carry the same phrasing.

Why it matters

• "Opt-in" is meaningless — these are the hosts, not an alternative to something.
• "V2 services" reads as though a V1 service graph is still live and selectable.
• "Must not reference V1 projects" is a boundary rule against a codebase that no longer exists in the solution, which makes the genuinely load-bearing boundary rules in the same list look equally theoretical.

Newly written READMEs (Composition, ManualRunFixtureGenerator, Fitness.Tests, Plugins.Tests, Worker.Tests, and the two ClientCustomerLookup test projects) already use the post-migration phrasing and can serve as the target style.

Scope

Mechanical pass over the 16 affected files:

grep -rln "for V2\|Opt-in\|V1 projects" Source/*/README.md Tests/*/README.md

• Drop "Opt-in" where it means nothing.
• Drop "V2" as a qualifier on services, layers and hosts.
• Drop "Must not reference V1 projects" — keep every other boundary rule in the list untouched, since those are real and are enforced by Tests/ParityBench.NET.Fitness.Tests/ArchitectureFitnessTests.cs.

Docs only. No behaviour change, no code touched.

Check afterwards

ArchitectureFitnessTests should still be the source of truth for what each README's Boundaries section claims — worth confirming that each remaining rule in prose has a corresponding assertion, and filing anything that does not.