Drop the implicit Entity[] to Entity conversion as well

[Rafael-SOWNet]

Closes #861.

#853 removed the implicit conversion from List<Entity> because it made three params overloads uncallable, and kept the one from Entity[] on the narrow ground that it never produced that ambiguity — an array binds to the params overload in its normal form by an identity conversion, which wins outright.

True, and beside the point. As @Happypig375 put it on the issue:

Note that converting an array to a set is inherently information-losing because it removes order and duplicate elements. This shouldn't even be a conversion at all; explicit set construction is used for basically all the set types out there.

An array carries an order and can repeat an element; a set has neither. The conversion silently discarded part of what it was handed, and that disqualifies it on its own — the question to ask of an implicit conversion is what it loses, not whether it breaks an overload today.

Entity set = new Entity[] { 1, 2, 3 };          // no longer compiles
Entity set = new FiniteSet(1, 2, 3);            // say it
Entity set = new Entity[] { 1, 2, 3 }.ToSet();

Blast radius, measured before writing anything

Removing the conversion broke exactly one place in the repository: the test from #853 that pinned it. Nothing in the library, no other test, no sample, no wrapper.

That test now asserts the opposite and still earns its keep the same way — the file compiling is what says the conversion has not come back, which no runtime assertion could catch.

PublicApi.txt updated, and the BREAKING-CHANGES.md entry from #853 is widened to cover both conversions as one story, including why keeping this one was the wrong call.

Verification

• 6084 C# tests pass, 0 failed
• 130 F# wrapper tests pass
• PublicApiSurfaceTest green

Breaking, so it wants the 2.0 window — which is the whole reason the question was filed rather than left as a comment.

🤖 Generated with Claude Code