SQL backend: joins, full predicates, OFFSET/COUNT, pypika-free renderer

[adsharma]

Query chains already describe reads (filter/project/order/take); this makes the SQL backend execute them instead of just spelling single-table queries.

What

Joins + predicate language (sql_builder.py)

• TABLE/ALIAS overrides on query classes (MembershipQuery → memberships)
• visit_edge emits INNER JOIN via a new JoinOn(left, right) edge context
• Predicates parsed as real AST (they arrive as source text in ast.Expr): AND/OR, is None/is not None, in (empty set matches nothing, not invalid SQL), call-form like(col, pat) / match(col, q) (FTS5 via new MatchCriterion), desc()/lower(), multi-key and bare-column order keys
• skip(n) op (OFFSET), visit_count, qualified project()

Runner (query.py)

• Empty-leaf table roots (MembershipQuery([])), to_sql_string(), to_rows(conn) (DBAPI → list of dicts)

Renderer (sql_render.py, new — drops pypika)

• ~130-line internal renderer: double-quoted idents, every literal a ? placeholder with params (stable plans, user input never touches SQL text)
• Removes the sql extra (pypika) from pyproject

Also: lazy polars import (hard import broke SQL-only users).

Verified

• fquery suite: 49 passed
• Byte-identical vs hand-written db.exec SQLAlchemy reads on a 60-user/200-message database: sidebar (JOIN+AND+LOWER order), message windows (DESC keysets, OR anchor predicates), autocomplete (LIKE), counts, IN/empty-IN/IS NULL, FTS MATCH (parameterized) — 12/12 checks
• Writes deliberately untouched (stay on db.exec)

Example output:

SELECT "membership"."involvement", "room"."type" FROM "memberships" "membership"
JOIN "rooms" "room" ON "membership"."room_id"="room"."id"
WHERE ("membership"."user_id"=? AND "membership"."involvement"<>?)
ORDER BY LOWER("room"."name"), "room"."id"