fix(adapters): transaction outcome, silent driver errors, await, and CI running the tests

[JustGodWork]

Seven changes covering the async error path, the built-in promise and the CI. Based on #2, review #1 and #2 first.

Every successful transaction was reported as a rollback. finish(committed and nil or "..."): true and nil is nil, which falls through to the error string, so the callback always received it. The COMMIT had happened, the caller saw a failure, and a naive retry ran the whole transaction a second time. oxmysql is the only adapter advertising transaction support, so the feature was unusable. The self-test covers transactions with a mock that short-circuits that exact line.

No driver error ever reached the caller. nanos passed nil as the error unconditionally on the async path, so a failed query read as an empty result set: find() on a missing table resolved nil, meaning "not found", instead of rejecting. The synchronous path handled it correctly, which is what gave the omission away. oxmysql now catches a raising export, and inside a transaction treats a nil return from query() as the failure oxmysql documents it to be, rather than an empty result the transaction body keeps working from.

Failed statements are now logged through the configured logger. A driver error previously only reached the rejected promise, and the most common call style, no :catch and no :await, discards it. A failed write produced no output at all on a live server.

await() could return before the promise settled. One yield, no loop, so any host scheduler resuming the coroutine made it return a nil value. FiveM and nanos both run their own scheduler, and the built-in provider is the default. The waiting coroutine was also stored in a single slot, so a second waiter on the same promise replaced the first, which was then never resumed at all.

queue_until_ready leaked its callbacks. _flush_ready only ran on the success path, so a failing sync() left every queued operation with its callback never invoked: no resolution, no rejection, no timeout, and any awaiting coroutine suspended for good. That is exactly the scenario the option exists for, a database not reachable at boot.

PostgreSQL was mapped to the mysql dialect as "close enough for our SQL". It is not: that dialect quotes with backticks and appends ENGINE=InnoDB, both rejected at the first token, while supports_returning still advertised the engine as supported. It now raises with a message pointing at the alternatives.

CI ran build.lua and pushed dist/ to master without ever running the test suites, so nothing stood between a source regression and the published bundle. Both suites now run against the freshly built dist/ and a failure stops the job before the commit step.

Known limit, not addressed here: a callback the driver never invokes at all still hangs. That needs a timeout the adapters cannot provide on their own.

Suite: 341 passing, 260 before this series.