feat(core): page store queries under signed, version-bound cursors

[nickruigrok]

Fourth of five stacked PRs for GRA-243. Security: needs human review before merge. Stacked on #391; this PR's own changes are the last two commits.

Threat model (written first; also in apps/core/src/store-cursors.ts)

A cursor is <version>.<sealed anchor>.<tag>.<stable tag>, every part canonical base64url.

• The anchor (the last record's ID and order values) is sealed with AES-GCM.
• Both tags are HMAC-SHA256 over the version, the sealed anchor and a digest of the binding.
• The tag and seal keys are derived with HKDF (separate labels) from one random key kept in the store's own SQLite (sdk_store.cursor_key, migration 0004). The key is minted by the store's first page and cleared at purge.

Threat	How it's closed
Forging or editing a cursor	Both tags are checked in constant time before anything is acted on, the version included. The anchor is decrypted only after. Otherwise: data.invalid_cursor. Other stores' keys differ. Every part must be canonical base64url, so no malleable spellings.
Reusing a cursor for another query or caller	The tags cover a digest of store, App, person, roles, table, index, range, filter and order, recomputed from the request and the core-resolved scope and never read from the cursor. A mismatch is data.invalid_cursor.
A cursor outliving its generation (spec 9.2)	The stable tag covers the binding without its generation (App version, schema hash, emitter version). If the stable tag verifies but the full tag doesn't, or the format version differs, the answer is data.cursor_expired. That is only told apart once a tag verified, so it's no oracle for strangers. An ID-only cursor whose record is gone also expires.
Leaking data through a cursor	Cursors are opaque: record IDs and values are encrypted (decision recorded on GRA-243).
Unbounded size	At most 4 KiB; a longer cursor is refused at the boundary as data.invalid_query. When the values don't fit, only the ID is sealed, and the next page looks the record up under the same access.
Deep pages scanning without bound	Each page reads through index seeks, one index range each, deepest first. After a left-out anchor value the seek is >= sentinel (a range, never a walk over left-out entries). Managed NOT NULL fields get no left-out step. Seek terms are top-level conjuncts with the range's, and the 10,000-entry and 16 MiB bounds apply across all of a page's seeks.

What

• readPage, pagePlans and seeksAfter in store-queries.ts. The planner gains anchors and seek.
• StoreHost opens the cursor, reads the page in one transaction and seals the next cursor. It answers spec 9.2's envelope.
• StoreHost.explainPage plans every seek, for tests only.
• New errors: data.invalid_cursor and data.cursor_expired.

Tests

apps/core/test/store-cursors.test.ts, in workerd through OpenStore and the DO:

• Pages add up:
  • to collect, in both orders, with the last page uncursored;
  • along an index through missing, null and values, with page sizes 1, 2 and 3 in both directions;
  • across 10,050 records in 101 pages with no scan_limit;
  • with a record inserted between pages appearing once.
• Opacity: the cursor text, decoded part by part, contains neither record IDs nor values.
• Refusal and expiry:
  • the same cursor answers the right page;
  • a forged cursor, an edited seal, both tags edited, a non-canonical version spelling and a later format version all give invalid_cursor;
  • another order, index, range, table, filter, person, role, App or store gives invalid_cursor;
  • another App version or schema hash gives cursor_expired, and so does a cursor with only its full tag edited.
• ID-only fallback: long values give an ID-only cursor that pages correctly and expires when its record is deleted.
• Owner-only tables: pages hold only the caller's records with another owner's interleaved, in both directions; descending ID-only pages work through null and left-out values.
• Seeks: EXPLAIN of every seek statement (asc after missing, null and value; desc after value and null; the default order) shows SEARCH … USING INDEX with no SCAN or TEMP B-TREE. The scan bound applies across two seeks. Paging carries on from a full anchor whose record moved or whose next record was deleted.

Results: vp check is clean. vp test on store-cursors (12 tests), store-queries and data-store-lifecycle passes 52 tests.

[nickruigrok]

@greptileai review

[nickruigrok]

@greptileai review

[nickruigrok]

@greptileai review

[nickruigrok]

@greptileai review

[nickruigrok]

@greptileai review

[nickruigrok]

@greptileai review

[greptile-apps]

Confidence Score: 5/5

[Critical impact] The reviewed changes appear safe to merge.

Summary

The PR adds paged store queries with encrypted, signed cursors tied to the caller, query, and version.

• Store queries return results one page at a time.
• Page cursors hide their anchors and stay tied to one query.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Read cursor] --> B[Check both tags]
  B --> C{Stable tag verifies?}
  C -->|No| D[data.invalid_cursor]
  C -->|Yes| E{Full tag and format match?}
  E -->|No| F[data.cursor_expired]
  E -->|Yes| G[Decrypt and check anchor]
  G --> H[Read next page]

Loading

_{Reviews (2) · Last reviewed commit: "fix(core): verify both of a cursor's tag..." · Reviewed by Greptile}

[nickruigrok]

@greptileai review