[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:141-144), 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.

Related behaviour

• 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. An item already stored under such a key, by ImportTable or by a BatchWriteItem or TransactWriteItems before this change, can no longer be read, updated or deleted through GetItem, UpdateItem, DeleteItem or the batch and transaction paths above, which refuse the key before the lookup. Scan still returns it.
• 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, with main at abf8082: 4 tests fail here and 35 on fix(core): range check number exponents as DynamoDB does #619's first revision; 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. With main at abf8082, cargo test --workspace --exclude extenddb-storage-cassandra: 1,817 passed, and cargo test -p extenddb-storage-cassandra --lib: 61 passed. On the rebased branch, cargo +1.88.0 test -p extenddb-core: 721 passed.

Merging with open PRs

With main at abf8082, 13 of the 17 then open PRs that touched these files merged cleanly. #433 conflicted in put_item.rs and transact_write_items.rs; both sides can be kept. #399, #507 and #597 conflicted 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.

Rebase on #619 at bfde5fd

#619 was rebased onto main 817b240 after this branch was cut, and this branch is now stacked on #619's new head instead of its first revision (95997b6). The two commits of this PR apply to the new base without conflicts and with the same patch IDs, so their code is unchanged. The conflict GitHub showed in crates/core/src/validation/number.rs came from #619's first revision, which this branch no longer carries.

The new base adds 15 main commits. Two of them touch files this PR changes or depends on:

• feat(core): backup format v1: streaming data files, sidecar manifest hash, typed backup ARN [backup/restore 3/4] #394 rewrote the AttributeValue deserializer, which still keeps an N value it cannot read as written. That code is now at crates/core/src/types/attribute_value.rs:141-144 for N and :244-245 for NS. feat(core): backup format v1: streaming data files, sidecar manifest hash, typed backup ARN [backup/restore 3/4] #394 also added the test exponents_at_the_ends_of_i32_classify_the_magnitude to number.rs, and it passes with this branch's zero check.
• fix(cassandra): record stream records for transacted writes #576 changed a comment in crates/engine/src/transact_write_items.rs, outside the lines this PR changes.

Main is now at f49c5f8, seven commits past 817b240 (#395, #412, #638, #511, #680, #473, #429). None of them changes a file this PR touches, and this branch merges with it without conflicts.

On the rebased branch, the number_validation filter passes 50 of 50 against a SQLite server and a PostgreSQL server built from it. With only this PR's wire files applied to #619's new head it fails 31 of 50, the same counts as before the rebase. tests/test_update_item_number_validation.py and tests/test_item_operations.py pass 134 of 134 on each backend. cargo +1.88.0 test -p extenddb-core passes 721 tests.

CI passed all 29 checks on 41bc6e43a.