[godronus]

Summary

Stacked on #8 (base feat/db-interface): async variant of the SQL interface for JS.

• deps/db/sql.wit: interface gcore:db/sql. database.query / batch return future-query-result / future-batch-result (subscribe() -> pollable, get() -> option<result<...>>, result returned once). open stays synchronous. Shares sql-types with sql-sync.
• deps/io/package.wit: wasi:io@0.2.3 (needed for pollable)
• world.wit: new world reactor-async { include reactor; import gcore:db/sql@0.1.0; }; world reactor unchanged

The WIT documents the ordering rule: started calls run independently (order not guaranteed); dropping a future abandons the result, the statement may or may not apply.

Decisions needed

#	Decision	Proposal
1	Interface vs version	A second interface in 0.1.0 (like cache-sync / cache), not a version bump: sync and async coexist in one host
2	P2 pollables vs P3	Pollables now (same pattern as wasi:http futures); WASI P3 async func later as gcore:db@0.2.0
3	New world reactor-async	Keeps wasi:io out of reactor, so the Rust SDK (binds reactor, stays on sql-sync) is unaffected; the engine and sdk-js bind reactor-async
4	wasi:io version	0.2.3, matching sdk-js (StarlingMonkey); hosts link any 0.2.x semver-compatibly

Engine design + measurements: docs/db/ASYNC.md in G-Core/FastEdge (branch feat/db-interface-async). Promise.all of 3 queries: 617 ms sync → 319 ms async.

Related: #8 (base), G-Core/FastEdge#660, G-Core/FastEdge-sdk-js#157