[godronus]

Summary

Stacked on #155 (base feat/db-interface): fastedge::db/sql moves to the async gcore:db/sql interface. JS API unchanged.

• runtime/fastedge/builtins/db-sql.cpp: query / batch start the host call and return a pending Promise; one StarlingMonkey api::AsyncTask per call (SqlTask) waits on the host future's pollable, reads the result, drops pollable and future, and settles the Promise. Argument errors reject the Promise.
• merge-wit-bindings.js: runtime world includes gcore:fastedge/reactor-async; skips FastEdge-wit's deps/io (StarlingMonkey's host APIs already provide wasi:io@0.2.3)
• types/fastedge-db-sql.d.ts: documents concurrency and ordering (await a write before relying on it; batch for ordered/atomic work)
• runtime/FastEdge-wit → G-Core/FastEdge-wit feat/db-interface-async; bindings regenerated

Measured (fastedge-run → Neon, median of 7)

	sync (#155)	async (this)
1 query	312 ms	326 ms (noise)
3 queries, Promise.all	617 ms	319 ms

Decisions needed

#	Decision	Proposal
1	Ship JS on async	Yes: no single-query cost, independent queries ≈ one round trip. If agreed, fold into #155 before release
2	Ordering contract	Un-awaited queries may run in any order (documented in the types). Behaviour change vs sync, where they ran in call order
3	Release order	Apps built from this branch also import gcore:db/sql and wasi:io/poll: engine on all edges → fastedge-test → this SDK

Testing

• Unit tests 457/457; Drizzle example and a Promise.all bench app end to end on fastedge-run (engine branch feat/db-interface-async) against Neon

Engine side + full design: docs/db/ASYNC.md in G-Core/FastEdge (branch feat/db-interface-async).

Related: #155 (base), G-Core/FastEdge#660, G-Core/FastEdge-wit#9