[P3][lens] Richer query surface: comparison operators and dot-path field queries #53

Summary

Roadmap item (README "Next": "a richer query surface; more query operators"; DESIGN.md section 6.1 defers query operators ($gt, $in, ...) and nested / dot-path field queries out of v1).

Why

Today find()/where() support only top-level field equality (deep structural, type-sensitive). Real document workloads quickly need range predicates (age > 30), set membership (status in [...]), and nested field addressing (profile.city).

Scope sketch (exploratory)

• Operator objects on predicate values ({ age: { $gt: 30 } }) or a small typed builder — decide against the no-SQL-text principle (DESIGN.md section 2 rejects a unified query language; this stays a per-lens surface).
• Dot-path addressing for nested documents, with the same eager undefined-predicate rejection the v0.2.0 validation added.
• Shared matcher stays single-sourced: the document lens's matches() is what the relational where() reuses — extend once, both lenses gain it.
• Operator semantics must be type-sensitive and total (define number-vs-string comparison behavior explicitly; no coercion).

Constraints

• Kernel unchanged. Backward compatible: bare values keep meaning deep equality.
• Pairs naturally with the secondary-indexes roadmap item (equality first, ranges later).
• Changeset (minor); gate green.