Restore first-class Effect semantics for query builders

[danieljvdm]

Context

This is the Hyper fork tracking PR for the query-builder Effect semantics fix.

Upstream PR: harrysolovay#2

Problem

During the Effect v4 migration, applyEffectWrapper() stopped making query builders real Effect values at runtime.

The types still say these builders are Effect.Effect<...>, but the wrapper only exposed asEffect() and Symbol.iterator. That left yield* query working while direct Effect combinators on the builder itself stopped working.

Broken before this change

const query = db.insert(users).values({ name: 'Ada' })

await Effect.runPromise(query.pipe(Effect.either))
await Effect.runPromise(Effect.map(query, (rows) => rows.length))

At runtime, this regressed because query.pipe was no longer defined on the builder.

The only working forms were the indirect ones:

const query = db.insert(users).values({ name: 'Ada' })

await Effect.runPromise(query.asEffect().pipe(Effect.either))
await Effect.runPromise(Effect.gen(function* () {
  return yield* query
}))

What this change does

This patch restores first-class Effect runtime semantics for wrapped query builders.

It adds the minimal Effect v4 runtime surface needed for builders to behave like real Effect values again:

• the Effect type marker
• pipe()
• Symbol.iterator
• an evaluation hook that delegates to execute()

asEffect() is preserved, and commit() is added as a compatibility alias to execute().

Testing

• pnpm --dir drizzle-orm exec vitest run tests/effect-query-effect.test.ts