Module batching

Batching store client.

Builds a StoreClient that coalesces concurrent requests of the same kind into a single batch, so a connector can serve many requests with one backend round-trip. A connector author supplies one Handler per request type to createBatchingStore; the returned client routes every call through a Broker that queues like-typed requests and hands each handler the whole batch it accumulated.

Four request types partition the work, each with its own handler:

• detect — probes whether each Detect entry exists in the store
• lookup — materialises each Lookup against its model; multi-valued slots reached by the model may be delegated to the select handler via Broker.select
• select — materialises each Select collection (see Query for the admitted forms); element resources reached by the query may be delegated to the lookup handler via Broker.lookup
• modify — creates, updates, or deletes each Modify target

Retrieval is driven by the requested model and query, not by the stored graph: lookup and select hand work back and forth, lookup spawning a select for each multi-valued slot its model reaches and select spawning a lookup for each element resource its query reaches. The handover recurses through this alternation and bottoms out where the model or query stops nesting, so each request descends exactly as deep as it asks for, however deep the underlying graph runs.

Handlers run concurrently and forward nested requests to one another through the Broker, so a handler must not assume any ordering between handlers, and must await every nested promise it issues before settling the request that depends on it. Correctness rests on this data dependency alone, not on handler scheduling.