[pdevito3]

Why

The in operators ^^ and !^^ threw QueryKitParsingException on a property that is configured with HasConversion<string>(). QueryKit sent the list to the single-value (string) constructor path. Now QueryKit converts each list item with the (string) constructor.

Closes #217

What changed

• For an in-operator list on a HasConversion<string>() property, QueryKit now builds an array of constants. It uses the same list check, item split, and value conversion as other types.
• A list item that does not convert throws ParsingException with the value, the property name, and the type.

Scope

• Covers structs, nullable structs, reference types, and properties with a query name.
• Each list item is text. "null" is the text null, the same as in a string list.
• A single value that does not convert still throws the exception of the constructor. A value that does not convert on a HasConversion<string> property throws FormatException, not ParsingException #219 tracks this.

Tradeoffs

This replaces #218. That PR built its own bracket check and its own item parsing. As a result, Email == "[a]" failed, edge quotes were removed from list items, and "null" became a null.

Blast Radius

The change runs only for a list on a HasConversion<string>() property with a (string) constructor. Before, that input always threw. With other operators, a value in brackets, such as Email == [a] or Email == "[a]", is still one value, and a test guards it.

Verification

• QueryKit.IntegrationTests against Postgres: Email ^^ [...] gives WHERE p.email IN (...) with the correct rows. Before the fix, it threw the error from The in operator (^^, !^^) does not work on a property with HasConversion<string> #217. 396 of 396 pass.
• QueryKit.UnitTests: 880 of 880 pass. The 10 new list tests failed before the fix.

[pdevito3]

Review gate note. One low finding stays open: ^^* and !^^* are case-sensitive on a HasConversion<string>() property. The case-insensitive path runs only when the property type is string. ==* on main has the same limit for one value, so this PR does not add it. The other low finding (an unquoted [...] with == threw) is fixed with the op.TakesList() guard and a test.