fix(dynamodb): cross-type relational comparisons in FilterExpression don't match

[vieiralucas]

Cycle-6 bug-hunt backlog (T1.12).

A FilterExpression / KeyConditionExpression relational comparison (<, <=, >, >=, BETWEEN) across mismatched attribute types wrongly matched: compare_attribute_values falls back to Ordering::Equal on a type mismatch, which satisfies <=/>=/BETWEEN. So n <= :s (Number attribute vs String value) returned the item, and an optimistic-lock version >= :v guard could wrongly pass. The relational operators now require both operands to share a scalar type (S/N/B) — DynamoDB only compares same-typed values. (=/<> already used exact typed equality; the PartiQL compare_attr path already returned no-match for cross-type.)

E2E asserts n <= :string doesn't match while n <= :number does. dynamodb lib (322) green. Builds clean; clippy -D warnings clean.

---

Summary by cubic

Fixes DynamoDB FilterExpression/KeyConditionExpression so relational comparisons don’t match across mismatched types. Relational operators now require both sides to share a scalar type (S/N/B), preventing false positives like n <= :s and protecting optimistic-lock guards.

• Bug Fixes
  • Added comparable_types and gated <, <=, >, >=, and BETWEEN on same-type operands (S/N/B).
  • Wired the guard into key_cond_simple_comparison and key_cond_between; equality/inequality remain exact typed.
  • Added e2e test verifying n <= :string yields no match while n <= :number matches (addresses Linear T1.12).

^{Written for commit 5bde3ce. Summary will update on new commits.}