[LeeroyHannigan]

Part of #618. Stacked on #619 (target branch fix/616-number-exponent-overflow), whose exponent rules these checks use.

What changed

Only the PutItem item and UpdateItem's update values ran number validation. AttributeValue keeps an N value it cannot read as written (crates/core/src/types/attribute_value.rs:105-108), so every other operation used values such as abc and 1E126 as written: BatchWriteItem and TransactWriteItems stored them, GetItem and DeleteItem looked them up, and an N partition key written that way became a partition of its own.

This PR checks the N and NS values on these paths, with the text DynamoDB gives on each:

Path	Message on DynamoDB and here
GetItem, BatchGetItem and TransactGetItems keys	the number message, no prefix
DeleteItem and UpdateItem keys, PutItem and DeleteItem ExpressionAttributeValues	1 validation error detected: and the number message
BatchWriteItem puts (keys, attributes, NS members, nested L and M) and delete keys	the number message, no prefix
TransactWriteItems Put items, Update, Delete and ConditionCheck keys	the number message, no prefix
TransactWriteItems ExpressionAttributeValues	ExpressionAttributeValues contains invalid value: <message> for key :v

The new checks are in crates/core/src/validation/number/operations.rs, with one or two call sites in each of eight engine handlers. validation/mod.rs is not changed.

BatchWriteItem, TransactGetItems and TransactWriteItems read a number with a 32-bit exponent and scale on DynamoDB, and the other operations with a 64-bit exponent. So 10E2147483647 is Number underflow on the first three and Number overflow on the rest, and 1E2147483648 cannot be converted on the first three. validate_number_i32_scale reproduces the 32-bit reading, and a unit test runs both readers over 4,000 generated strings and fails if they answer differently outside the four documented differences.

Order against a second fault

Each check is placed where DynamoDB reports it, unless that position would change the answer to a two-fault request that main already answers as DynamoDB does:

• GetItem, DeleteItem, UpdateItem, BatchGetItem and BatchWriteItem report a malformed number ahead of the table lookup; PutItem reports item numbers ahead of the mixed-parameter check and the lookup, and value numbers after the mixed-parameter check.
• TransactGetItems checks each item's key right after its projection; TransactWriteItems checks each action right after its expressions are parsed. The ClientRequestToken check now runs before the actions, as on DynamoDB.
• Where DynamoDB reports the number first and main reports the other fault, this branch keeps main's answer: a duplicate item or a missing table in TransactGetItems, a missing table in an earlier TransactWriteItems action, and an expression fault in the same action.
• BatchWriteItem and BatchGetItem visit tables in name order. DynamoDB's order for two tables was neither body nor name order on four sends, and not stable for BatchGetItem.
• In a PutItem item, numbers are checked before nesting depth, as on main. DynamoDB follows the attribute order of the request body, which Item does not keep.

Measured

DynamoDB in us-east-1, 2026-10-27, every request sent twice with the same answer both times: 20 paths with abc, 1E126, 0E126 and a control; 31 paths with 24 values; three probes of two-fault order; token, exponent marker and fraction rows. A refused batch or transaction writes nothing on DynamoDB and on this branch; main stored the whole request, invalid values included.

Against main, on the same probes: no request that main answers as DynamoDB does is answered differently here, by exact text or with the 1 validation error detected: prefix ignored, apart from Unicode digits below.

Not changed here

• Zeros such as 0E126 and 0.0E-130 are refused on DynamoDB and stay accepted as 0. AttributeValue normalizes them before any check runs, and refusing them there makes Query pk = 0E126 miss the item at 0 and ImportTable store 0E126 as written, because Query, Scan (fix(query): check Query values against the key schema and the number rules #544, fix(scan): check the numbers in ExpressionAttributeValues as the service does #562) and ImportTable do not validate numbers yet. BatchWriteItem, TransactWriteItems and other operations store N values that fail number validation as written #618 stays open for them. The unit test zero_with_i32_exponent_stays_accepted_until_query_scan_and_import_validate marks the place to change.
• Unicode decimal digits (５, ١) are accepted by DynamoDB and stored as ASCII. Main refuses them on PutItem and stored them as written on the paths it did not check; this branch refuses them on every path it checks. Unicode decimal digits in N values: refused on writes, compared as text on reads #565 covers reading them.
• An NS with two equal malformed members answers the duplicates error, where DynamoDB answers the number: the duplicate check runs while AttributeValue is read.
• crates/server/src/leading_keys.rs authorizes a BatchGetItem or BatchWriteItem against the keys it can read and leaves out one it cannot. The engine now refuses such a request before any data is read or written, and that refusal is what keeps the partial key set from reaching data.
• ImportTable imports an invalid N as written; DynamoDB's answer there was not measured.
• PutItem item errors and UpdateItem ExpressionAttributeValues keep their current text.

Tests

• Unit: 18 tests in operations/tests.rs. In number.rs the two zero tests gain the measured rows and the guard test is renamed.
• Wire: number_validation_all_ops.rs (27 tests) and number_validation_order.rs (11). Against SQLite dev-mode servers, the number_validation filter passes 50 of 50 here and fails 31 on fix(core): range check number exponents as DynamoDB does #619's head.
• Full wire suite, one thread: 4 tests fail here and 35 on fix(core): range check number exponents as DynamoDB does #619's head; none fails here that passes there. The 4 fail on both (capacity throttling and a vector index test).
• cargo fmt --all -- --check and cargo +1.97.0 clippy --all-targets -- -D warnings are clean. cargo test --workspace --exclude extenddb-storage-cassandra: 1,817 passed. cargo test -p extenddb-storage-cassandra --lib: 61 passed. cargo +1.88.0 test -p extenddb-core: 542 passed.

Merging with open PRs

13 of the 17 open PRs that touch these files merge cleanly. #433 conflicts in put_item.rs and transact_write_items.rs; both sides can be kept. #399, #507 and #597 conflict in delete_item.rs and put_item.rs on comment lines, where both sides can be kept, and in transact_write_items.rs, where #399 splits the action loop into phases. There the per-action check goes at the head of phase 1's per-item step; with it, three rows where this branch answers the number ahead of a nested value too deep move to the nesting error, because #399 checks nesting in a later phase.