fix: match real DynamoDB on Scan and Query ExclusiveStartKey malformations

[yesyayen]

What

Tighten ExclusiveStartKey validation in Scan and Query so every malformed request returns ValidationException matching real DynamoDB.

Why

Two malformations are still accepted, where real DynamoDB rejects them:

Case	Real DDB	extenddb on main	This PR (extenddb after)
{pk only} on composite	ValidationException	ValidationException	ValidationException
{sk only}	ValidationException	ValidationException	ValidationException
{} empty	ValidationException	ValidationException	ValidationException
{pk, sk, extra non-key attr}	ValidationException	Accepted (wrong)	ValidationException
{pk wrong scalar type, sk}	ValidationException	Accepted (wrong)	ValidationException
{pk, sk} valid	success	success	success

Wire-format messages are mirrored verbatim:

• Scan, base table: The provided starting key is invalid: The provided key element does not match the schema
• Scan on index / Query (any case): The provided starting key is invalid

Builds on #66

Testing done

• Added 10 pytest cases in tests/python/test_scan_edge_cases.py covering the malformations real DynamoDB rejects.
• The new cases also verify the operation-specific verbatim message: long form for Scan on a base table, short form for Scan on an index and for Query.

Checklist

• I have read CONTRIBUTING.md
• All tests pass (cargo test --workspace)
• Code is formatted (cargo fmt --check)
• Clippy is clean (cargo clippy -- -W clippy::pedantic)
• I have added or updated tests for new functionality
• I have updated documentation if behavior changed (no doc change required; REQ-ERR-001/002 in docs/design/01-requirements.md already specifies ValidationException for input validation, this PR makes the implementation match the spec)
• Breaking changes are noted below (none)

Breaking changes

None.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache License 2.0 and I agree to the Developer Certificate of Origin (DCO). See CONTRIBUTING.md for details.

[jcshepherd]

Hi Anand - Thanks for the PR! Could I ask you to take a look at #66 (which has been merged to main) and see if that resolves some/all of the issues you've covered, or improves on it in areas? Happy to review but would like to understand (and minimize if possible) the overlap.

[yesyayen]

Hello Joel, thanks for taking a look. I did look at #66 and this PR builds on top of it. There are 2 cases from the table that #66 doesn't cover: {pk, sk, extra non-key attr} and {pk wrong scalar type, sk}. On current main both still return success; real DDB returns ValidationException, which this PR fixes.