v0.13.0

Added

• PartiQL now works in the browser. The wasm engine serves ExecuteStatement, BatchExecuteStatement and ExecuteTransaction, where it previously answered all three with a 501. Behaviour matches the native build statement for statement, including the RETURNING projections, the per-statement error codes BatchExecuteStatement reports, and ClientRequestToken idempotency on ExecuteTransaction. The engine's advertised capability list grows from 14 operations to 17; CONTRACT_VERSION is unchanged at 1, since adding an operation is additive, so a pinned client keeps working. The engine bundle grows by about 143 KB raw and 53 KB gzipped, which is the parser and executor now being reachable from the wasm entry points.

Changed

• Breaking (Rust API): wasm_api::dispatch and wasm_api::dispatch_http take a DispatchContext, which borrows the idempotency caches a ClientRequestToken needs. Both are behind the wasm-sqlite feature, so a native library consumer is unaffected, and the #[wasm_bindgen] surface the npm package calls (open, execute, dispatchHttp, capabilities, contract_version) is unchanged. Callers of dispatch build a context from the new public TokenCaches. This is separate from CONTRACT_VERSION, which does not move.
• The wasm build's documentation no longer describes it as unverified. The preview label stays, and now rests on what remains unimplemented - TransactWriteItems, streams, tags and TTL - rather than on an absence of test data.

Fixed

• PartiQL SELECT on ExecuteStatement now paginates: NextToken is honoured and returned, and Limit bounds the rows evaluated rather than the rows matched, matching DynamoDB and the existing Query and Scan semantics. A filtered SELECT with a Limit can therefore return fewer rows than before for the identical request, and a page can come back short or empty while still carrying a NextToken, so callers should follow the token rather than treat a short page as the end of the result. A SELECT bound to a partition key now reads in ascending sort-key order, and its sort-key conditions are pushed into the read, so Limit paces against rows in the key-condition range rather than the whole partition; a condition a key condition cannot express falls back to the partition-wide read and filters as before. A NextToken is now rejected when replayed against a different statement or different Parameters, not just a different table, where it previously resumed the walk and silently skipped rows; the mismatch carries DynamoDB's NextToken does not match request message (captured eu-west-2) while an undecodable token keeps Invalid NextToken. Limit: 0 is rejected with the message DynamoDB's ExecuteStatement returns (the Scan-shaped wording, also captured); it previously read nothing and returned no token, making a paginated walk look complete.
• PartiQL SELECT COUNT(*) is removed. It was a dynoxide-only extension: real DynamoDB rejects the projection outright, so a statement that worked locally broke in production. A COUNT(...) projection now returns DynamoDB's exact ValidationException, the bare Unexpected path component message with the 1-based position of the COUNT token (captured eu-west-2), fired before the table-existence check, on ExecuteStatement, BatchExecuteStatement and ExecuteTransaction alike. Note this removes a previously shipped dynoxide feature rather than fixing it in place; there is no replacement, matching DynamoDB, where counting means paging the rows yourself or using Query/Scan with Select: COUNT.
• The wasm engine refuses a CreateTable carrying an enabled StreamSpecification or Tags, and an UpdateTable carrying a StreamSpecification, before creating or changing anything, with the same typed UnsupportedOperation envelope and 501 status the unimplemented operations use. Previously the table was created first and the stream or tag step then failed with a 500, so an AWS SDK retried the error and surfaced ResourceInUseException for the half-created table; the conformance suite's streams probe scored that as a failure where it now correctly records a skip. Every backend capability refusal (BackendError::Unsupported) now maps to this envelope rather than to a 500 InternalServerError, so a client - and an SDK retry policy - can tell a scope gap from a server fault.