[LeeroyHannigan]

Closes #427.

Summary

A Query whose KeyConditionExpression has no equality clause on the HASH attribute was refused with a parser sentence of ExtendDB's own. The service chooses the sentence from the key schema, and this change does the same.

Measured on the service on 2026-10-23 (every row repeated, identical answers):

Shape	Service sentence
Single HASH attribute, a clause names it (pk > :x, pk BETWEEN :x AND :y, begins_with(pk, :x), pk > :x AND sk = :y, sk = :x AND pk > :y, zz = :x AND pk > :y, GSI forms)	Query key condition not supported
Single HASH attribute, no clause names it (sk > :x, zz > :x, sk > :x AND zz > :y, zz = :x AND yy = :y, GSI forms)	Query condition missed key schema element: <HASH>
Two HASH attributes, or one HASH with several RANGE attributes, any operator, any attribute, including an N value on the HASH attribute	HASH key attributes h1, h2 must have equality conditions specified in the query
Two conditions on one attribute	Invalid KeyConditionExpression: KeyConditionExpressions must only contain one condition per key
Undefined #name or :value in the key condition, equality shapes included	Invalid KeyConditionExpression: An expression attribute name used in the document path is not defined; attribute name: #n (value form likewise), reported before any of the above

Ordering, measured: unused values, filter syntax, projection syntax, the Select conflicts and undefined key references come before this refusal; an ExclusiveStartKey fault and an oversized key value come after it.

Changes

• crates/core/src/expression/key_condition/no_hash_equality.rs: KeyCondition::lacks_hash_equality and refuse_without_hash_equality, choosing the sentence from the key schema.
• crates/core/src/expression/key_condition/references.rs: KeyCondition::validate_references, the undefined-reference refusal with the prefix.
• The parser records two non-equality clauses instead of refusing them so the engine can choose the sentence.
• handle_query calls validate_references for every key condition, then the refusal after validate_select_projection and before the partition key resolution.

Tests

• Unit tests in no_hash_equality/tests.rs and references.rs.
• tests/python/test_query_lone_non_equality.py, 67 rows, each asserting the exact sentence: 67 passed against the service and on a SQLite build of this head. The previous head fails 25 of them.
• Regression on the same server: test_query_scan.py, test_multipart_gsi.py, test_read_paging.py, test_vector_index_query_scan.py and the expression validation files, 191 passed.

Merge note

This branch conflicts with #429 in crates/engine/src/query.rs (both touch the partition key block). Whichever merges second gets rebased; the resolution is prepared and keeps both orders: on a single-attribute schema the type check in #429 precedes this refusal (row 427-8c, pk > :n with an N value on an S key, Condition parameter type does not match schema type), and on a multi-attribute index the HASH wording precedes the type check (h > :n measured as the HASH sentence).

Pre-existing, measured, not changed here

• <>, NOT, OR, IN and contains in a key condition: the service says Invalid KeyConditionExpression: Invalid operator used in KeyConditionExpression; ExtendDB's text differs.
• pk = :x AND z > :x (second clause on a non-key attribute): Query condition missed key schema element: sk on the service, 200 here.
• begins_with(pk, :n) on an N key: the operand type sentence on the service; covered by fix(query): classify and order key conditions on a multi-attribute GSI the way the service does #429's type check.
• Select=ALL_PROJECTED_ATTRIBUTES without an index: ExtendDB's text lacks the 1 validation error detected: prefix.
• An undefined :value in a FilterExpression is refused up front by the service and only noticed at evaluation here.

These will be filed as one issue.

Overlap with other open PRs

#484 refuses a second condition on one key attribute (KeyConditionExpressions must only contain one condition per key) in parse_key_condition for every key schema, which covers pk > :x AND pk < :y. Once #484 merges, the copy of that refusal in no_hash_equality.rs can go.