Legacy QueryFilter, ScanFilter and KeyConditions: eight differences from DynamoDB #477

These remain on the legacy condition paths after #399, which brings the operator, value count and type checks of QueryFilter, ScanFilter and KeyConditions to the service's rules and messages. Each one is present on main as well. Measured against Amazon DynamoDB in us-east-1 on 2026-10-23, on an empty table and on a table with items.

1. Two legacy condition entries that are both invalid: the service names the second entry in map order, ExtendDB names the first.
2. Query with a QueryFilter on a primary key attribute: the service refuses it (QueryFilter can only contain non-primary key attributes: Primary key attribute: pk), ExtendDB returns 200.
3. ScanFilter EQ with an N AttributeValue whose value is not a number: the service reports the numeric conversion (The parameter cannot be converted to a numeric value: <value>), ExtendDB returns 200.
4. ScanFilter BEGINS_WITH with an N AttributeValue whose value is not a number: the service reports the numeric conversion first, ExtendDB reports the operator against type message.
5. KeyConditions on the sort key with a value whose type is valid for the operator but is not the schema type: the service refuses it with the schema type message, ExtendDB answers HTTP 500 (crates/storage/src/util/key.rs).
6. KeyConditions EQ or BEGINS_WITH with an empty string: the service refuses it, ExtendDB returns 200.
7. KeyConditions EQ on an S partition key with an N value: the service refuses it with the schema type message, ExtendDB returns 200.
8. BatchGetItem with ReturnConsumedCapacity TOTAL where every key is absent: the service returns one entry per table, ExtendDB returns an empty list.

Items 5 to 7 are the most visible to a client: one is a 500, and two accept a request the service refuses. Each needs its message measured again when it is fixed, and a wire test under tests/ that runs against the service and every backend.

Related: #108 (the original list of error differences), #399.