known issues: SQL = on a list or map misses a list written from Python (ArcadeData/arcadedb#10448) - #358

Fixes #357.

ArcadeData#10448 reaches Python users directly: Document.set, Vertex.set and GraphBatch.create_vertices store a Python int as a Long, a SQL literal such as [1, 2] parses to Integer elements, and SQL = compares list and map elements with Java equals(), so WHERE li = [1, 2] misses a list written from Python and li <> [1, 2] returns it.

• docs/guide/known-issues.md: a new entry (versions, what you see, the workaround), and the intro now says the first entry is an engine bug.
• tests/test_collection_equality_known_issues.py: the two workarounds (openCypher =, a named SQL parameter) as plain tests, and strict xfail tripwires on the SQL list and map literals, which fail the suite once the fix reaches the wheel. With a BY ITEM index on the list, SQL = is answered from the index and matches nothing (literal or parameter; SQL = on a list or map compares elements with Java equals, so [1L, 2L] is not equal to [1, 2] (CONTAINSALL, GROUP BY and Cypher say it is) ArcadeData/arcadedb#10448 comment 6291702807), so the entry says the parameter does not help there, and the test checks openCypher through the index with a tripwire on the parameter.
• docs/development/testing.md: the file's row in the test table.

Ran locally: uv run pytest bindings/python/tests/test_collection_equality_known_issues.py (3 passed, 3 xfailed on the 26.10.2 wheel), uvx pre-commit run --files on the three files, uv run mkdocs build --strict -f bindings/python/mkdocs.yml.

🤖 Generated with Claude Code