perf(sdk): batch invoke-path lookups with DataLoader semantics

[RhysSullivan]

What

Concurrent execute() calls in the same microtask window now share one storage query per table (tool, connection, integration) plus one policy-rule-set snapshot, instead of four point queries per call. Naive fan-out code — Promise.all over tool calls, code-mode loops, parallel MCP tool calls — no longer produces N+1 query storms.

Built on Effect Request/RequestResolver: each hot lookup on the invoke path is a request keyed by plain data, and a resolver serves the collected batch with a single OR-of-tuples query (keys deduped before hitting storage).

Behavior preserved

• No cross-batch caching. Every batch window re-reads storage, so read-your-writes and policy invalidation are unchanged. A batch of one is exactly the point query it replaced, so sequential callers see identical query patterns.
• Transactions bypass the batch window. Batches execute on a fiber forked with the first caller's context; inside fuma.transaction the handle rides on activeFumaDbRef, so a shared batch would read through the wrong connection. Transactional reads run the loader directly with exact isolation.
• Public API and error types unchanged; a missing row still surfaces as the same typed not-found error per caller.

Proof

invoke-batching.test.ts counts real queries through a spying FumaDb wrapper:

• 25 concurrent executes → at most 2 queries per table (was ~25).
• 2 sequential executes → exactly 2 point reads per table, no regression.
• A missing tool inside a batch fails alone with ToolNotFoundError; peers succeed.

Gates

format:check, lint, typecheck, and the full test suite (36 packages) all pass.

[github-actions]

Cloudflare preview

Torn down — the PR is closed.