feat: Add In operator edge cases

[Copilot]

Added 12 new test cases for IN operator edge cases:

Native list condition properties:

• float context value vs float[] condition property — should match
• int context value vs int[] condition property — should match
• float context value vs int[] condition property — should not match
• int context value vs float[] condition property — should not match

Comma-delimited string condition properties:

• float context value vs string comma-delimited floats condition property — should match
• int context value vs string comma-delimited ints condition property — should match
• float context value vs string comma-delimited ints condition property — should not match
• int context value vs string comma-delimited floats condition property — should not match

JSON-encoded list condition properties:

• float context value vs string JSON-encoded floats condition property — should match
• int context value vs string JSON-encoded ints condition property — should match
• float context value vs string JSON-encoded ints condition property — should not match
• int context value vs string JSON-encoded floats condition property — should not match

All test cases follow the existing naming convention and structure, with descriptive comments explaining each scenario. Float values use 2.0 (vs int 2) to test ambiguous cases that are equal in loose comparison but distinct in type-strict comparison. Native array values are now strings to comply with the JSON schema.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[khvn26]

@copilot for test cases involving floats, we should use values that add ambiguity when loosely compared — i.e. 2 vs 2.0, not 2.5.

[Copilot]

@copilot for test cases involving floats, we should use values that add ambiguity when loosely compared — i.e. 2 vs 2.0, not 2.5.

Updated all float test cases to use 2.0 instead of 2.5 for better ambiguity testing. Commit: 2abf80b

[khvn26]

@copilot make sure the new test cases are compliant with their JSON schema — "value" array values should be arrays of (numeric) strings.

[Copilot]

@copilot make sure the new test cases are compliant with their JSON schema — "value" array values should be arrays of (numeric) strings.

Updated native array values to use strings (e.g., ["1.0", "2.0", "3.0", "4.0"] instead of [1.0, 2.0, 3.0, 4.0]) to comply with the JSON schema. Commit: c8ed747

[gagantrivedi]

This is still a list of integer?

[khvn26]

Currently, we expect the engine to coerce the unmarshalled json-encoded values to an array of strings — see https://github.com/Flagsmith/flagsmith-engine/blob/3c28ed5a578c5782c3f289c51cab97cb0f4d6c09/flag_engine/segments/evaluator.py#L277-L287.

Is this a concern for Go and Rust?

[gagantrivedi]

This is a concern for Rust. When converting floats to strings, Rust removes trailing zeros—for example, 2.0.to_string() returns "2" instead of "2.0". This causes the IN operator tests to fail because the string representation of the float trait value ("2")
doesn't match the comma-delimited float values in the condition ("1.0,2.0,3.0,4.0").

[khvn26]

We've taken the discussion offline and couldn't come to a good conclusion yet — created #44 to address this.