docs: restore the trailing options arg on IDataEngine reads (#4486)

The `IDataEngine` block in data-engine.mdx wrote all four read methods with
two parameters, dropping the trailing `options?: BaseEngineOptions` that the
real contract gives each of them (packages/spec/src/contracts/data-engine.ts
:70/85/89/90).

The write methods in the same block each carried their own `options`, so the
block taught exactly the wrong model -- "writes take options, reads do not" --
and that is the misconception #4251 existed to fix. The parameter is not
incidental: the same `{ context }` object is correct as insert's 3rd argument
but was SILENTLY DROPPED as find's, so an intended `isSystem` bypass vanished
and control-plane reads came back empty once org-scoping hooks landed. Anyone
-- human or agent -- writing code from this block was being led back to the
pre-#4251 shape, against a failure mode that raises no error.

Adds `BaseEngineOptions` to the block's import list (the contract imports it
from the same module), and a callout recording the precedence the contract
states: `query.context` remains supported, and when both are given
`options.context` wins.

`content/docs/kernel/contracts/` is hand-written -- only `content/docs/
references/` is generated -- so no generator run is involved.

Fixes #4486

Author: claude

content/docs/kernel/contracts/data-engine.mdx

@@ -21,6 +21,7 @@ The canonical `IDataEngine` interface uses **QueryAST-aligned parameter names**
 
 ```typescript
 import type {
+  BaseEngineOptions,
   EngineQueryOptions,
   DataEngineInsertOptions,
   EngineUpdateOptions,
@@ -31,11 +32,12 @@ import type {
 } from '@objectstack/spec/data';
 
 export interface IDataEngine {
-  // Query
-  find(objectName: string, query?: EngineQueryOptions): Promise<any[]>;
-  findOne(objectName: string, query?: EngineQueryOptions): Promise<any>;
-  count(objectName: string, query?: EngineCountOptions): Promise<number>;
-  aggregate(objectName: string, query: EngineAggregateOptions): Promise<any[]>;
+  // Query (reads take the execution context in a TRAILING options argument —
+  // the same position the write methods take theirs)
+  find(objectName: string, query?: EngineQueryOptions, options?: BaseEngineOptions): Promise<any[]>;
+  findOne(objectName: string, query?: EngineQueryOptions, options?: BaseEngineOptions): Promise<any>;
+  count(objectName: string, query?: EngineCountOptions, options?: BaseEngineOptions): Promise<number>;
+  aggregate(objectName: string, query: EngineAggregateOptions, options?: BaseEngineOptions): Promise<any[]>;
 
   // Mutation (write ops also accept in-process WriteObservabilityOptions — see `update`)
   insert(objectName: string, data: any | any[], options?: DataEngineInsertOptions & WriteObservabilityOptions): Promise<any>;
@@ -65,6 +67,20 @@ export interface IDataEngine {
 
 All query methods use canonical **QueryAST parameter names**: `where`, `fields`, `orderBy`, `limit`, `offset`, `expand`.
 
+<Callout type="warn">
+**Reads take the execution context in the trailing `options` argument**, the same
+position the write methods take theirs — `find`, `findOne`, `count` and `aggregate`
+all accept `options?: BaseEngineOptions`.
+
+This matters because the mistake it prevents is silent. The same `{ context }` object
+is correct as the third argument to `insert`, and passing it as the third argument to
+`find` used to be **dropped without error** — so an intended `isSystem` bypass simply
+vanished, and control-plane reads started coming back empty once org-scoping hooks
+landed (#4251).
+
+`query.context` remains supported. When **both** are given, `options.context` wins.
+</Callout>
+
 ### find
 
 Executes a structured query with filtering, sorting, pagination, and field selection. Returns an array of records.