--aot: Bun.SQL internals fail ~25 type guards per query (PooledConnection, Query, SQLResultArray) #47456

What version of Bun is running?

1.4.4-canary.1+da867c60b

What platform is your computer?

Linux 7.0.0 x86_64

What steps can reproduce the bug?

// repro.ts
import { SQL } from "bun";

const sql = new SQL("postgres://postgres:password@127.0.0.1:5432/postgres", { max: 2 });
for (let i = 0; i < 3; i++) {
  const rows = await sql.unsafe("select $1::int as x", [i]);
  console.log(rows[0].x);
}
await sql.close();

bun build --compile --aot --aot-log-type-mismatches repro.ts --outfile repro
./repro

What is the expected behavior?

No type mismatches inside Bun's own bun:sql / internal:sql/* modules.

What do you see instead?

Every query fails the same 25 guard sites (21 once, 4 twice), all inside Bun's SQL internals, so each query takes the slow path. The objects are Bun's own native types but don't match the declared TS types of the built-in JS:

argument   bun:sql:105:22 (runOn): expected PooledConnection, got PooledConnection
argument   bun:sql:113:47 (onQueryConnected): expected PooledConnection, got PooledConnection
call-result bun:sql:86:10 (unsafeQuery): expected Query<T, Handle>, got built-in Query
argument   bun:sql:121:25 (dispatchToPool): expected Query<any, any>, got built-in Query
argument   internal:sql/pool:102:13 (bindQuery): expected Query<any, any>, got built-in Query
this       internal:sql/query:55:3 (#run): expected Query, got built-in Query
this       internal:sql/query:161:3 (then): expected Query, got built-in Query
this       internal:sql/query:104:3 (resolve): expected Query, got built-in Query
call-result internal:sql/pool:296:48 (createQueryHandle): expected SQLResultArray<T>, got Array
argument   internal:sql/postgres:127:53 (onResolvePostgresQuery): expected SQLResultArray, got Array
unknown    internal:sql/shared:31:10 (SQLResultArray): expected SQLResultArray, got Array
...

Two patterns:

• expected PooledConnection, got PooledConnection / expected Query, got built-in Query: the guard seems to compare against a different class identity than the one the runtime actually constructs.
• expected SQLResultArray, got Array: results are created as plain arrays and only later turned into SQLResultArray, so every guard typed SQLResultArray misses.

sql.close() also logs expected PostgresError, got built-in PostgresError at internal:sql/errors:29/32.

Additional information

Found while evaluating --aot on a TypeORM service running on Bun.SQL (#45631). In that service the SQL internals are the main remaining source of type mismatches on the hot path (~20+ per query).