ORM endCursor rejects cursors produced by its native pagination path #488

An indexed cursor query can return a native Convex cursor that its own endCursor path rejects.

Reproduce with seeded example projectAccess rows and the same where/order/with shape:

const options = {
  where: { userId, archived: false },
  orderBy: { projectCreatedAt: 'desc' as const },
  with: { project: true as const },
};
const first = await ctx.orm.query.projectAccess.findMany({
  ...options, cursor: null, limit: 1,
});
await ctx.orm.query.projectAccess.findMany({
  ...options, cursor: null, endCursor: first.continueCursor, limit: 20,
});

The second call throws Invalid pagination cursor for stream-backed pagination. Use the continueCursor returned by the same findMany query shape. It should read the bounded first-page window.

Source at main6415dc4c: query.ts selects the native fast path while endCursor is undefined, then switches to the advanced stream path when endCursor is supplied. stream.ts deserializes that cursor as JSON. The cursor producer and consumer disagree even though the caller preserves the query shape.

Confirmed with real example schema/ORM in convex-test during #452 review. This is separate from closed #460's cRPC field propagation. Ordinary initial/next-page projectAccess queries still pass. Keep the fix in the ORM cursor owner rather than adding a consumer fallback. No package patch included in #452/#487.