[iamralch]

Closes #13.

Problem

The page token carried only the order_by and the boundary values. A client could change its filter between pages and keep its page_token; the server then continued from that cursor under a different predicate and returned pages that matched neither filter, with no error. AIP-158 requires the filter to stay the same between pages.

Change

The cursor now carries a checksum of the filter, and the composer checks it alongside order_by.

• Cursor::with_filter(impl Into<WhereClause>) adds a filter clause, once per push_where call, in the same order.
• The token carries only a CRC32 checksum of the filter, never its SQL. A checksum can't be ANDed onto, so it's chained one clause at a time; empty clauses count for nothing, as in push_where.
• compose() computes the same chain over its own push_where clauses. A changed, added or dropped filter returns Error::CursorMismatch, whose message and docs now cover both order_by and the filter.
• The order_by keys stay in the token as before: the cursor needs them to build its comparison and to supply the ORDER BY, and compose() already compares them directly, so a checksum of them would add nothing.
• encode()/parse(token) keep their signatures.
• CURSOR_TOKEN_CHECKSUM_MASK is bumped (0x5eed_c0de → 0x5eed_c0df), so tokens issued before this change are rejected cleanly instead of misread.
• README and module docs are updated, including a stale CursorOrderByMismatch reference corrected to Error::CursorMismatch.

The commits show how the design changed: a request digest first, then the full filter in the token, then the filter checksum. Squash on merge.

For review

• Breaking: a cursor used together with push_where now has to carry the same filter (Cursor::new(order_by).with_filter(filter)), or compose() fails. Callers who don't attach it get CursorMismatch on page 2 instead of the old silent behaviour.
• The filter is matched clause by clause: push_where(a.and(b)) doesn't match with_filter(a).with_filter(b). The docs ask for the same clauses in the same order.
• CRC32 means a changed filter goes unnoticed with odds of about 1 in 4 billion. This catches client mistakes; it isn't a security check, since the token is already forgeable (an unkeyed CRC).
• Scope bound into the base query with bind_value (e.g. tenant_id = $1) isn't part of the filter, so it isn't checked. Scope added through push_where is.
• Both mismatches share Error::CursorMismatch. Splitting them into separate variants would be a small change if you want to tell clients which one changed.

Testing

• make lint, make test and make doc-check pass locally, and cargo check --no-default-features passes for both crates.
• New tests:
  • The filter checksum round-trips through the token, and only the same clauses in the same order match it.
  • The composer accepts matching clauses (including an empty push_where) and rejects a changed, added or dropped filter, and a missing tenant scope.
  • A SQLite end-to-end test pages a filtered query through Pager and a token, then shows a changed filter is refused.
• The PostgreSQL and MySQL tests skipped locally because no database URLs are set.