[FEATURE]: Effect-native Neon adapters with parity to Effect Postgres

### Feature hasn't been suggested before.

- [x] I have verified this feature I'm about to request hasn't been suggested before.

### Describe the enhancement you want to request

Please add Effect-native support for the Neon adapters, with API and integration parity with `drizzle-orm/effect-postgres` wherever the underlying transport supports it.

The goal is to use Drizzle queries directly in Effect programs while retaining the HTTP/WebSocket transport provided by `@neondatabase/serverless`.

#### Motivation

We currently use `drizzle-orm/neon-serverless` with a Neon `Pool` and `neonConfig.poolQueryViaFetch = true`. This lets eligible standalone queries use HTTP while interactive transactions use a WebSocket connection.

Our Effect services currently wrap Promise-based Drizzle operations with `Effect.tryPromise` through a small database service. The native Effect Postgres integration is appealing, but its documented `@effect/sql-pg` / `pg` setup would change our connection stack and give up this HTTP query path.

#### Requested behavior

- Effect-native query builders and relational queries that can be used directly with `yield*`, with typed failures.
- Layer-based initialization and integration with Effect logging/tracing and resource management, comparable to Effect Postgres.
- Preserve Neon HTTP execution for eligible queries, including the existing `poolQueryViaFetch` use case if supported by the integration.
- Effect-composable interactive transactions over Neon WebSockets.
- Interruption/cancellation propagation where supported, with transport limitations documented.

This could be dedicated Effect Neon adapters or a supported way to configure the existing Effect integration with Neon. The public API shape is less important than retaining the transport benefits without maintaining a custom Promise bridge.

Parity should respect transport capabilities: this request does not expect HTTP-only queries to gain session state or interactive transactions. HTTP batch transactions and WebSocket interactive transactions should retain their respective semantics.

Is this planned, or is there already a supported approach to achieve it?

#### References

- [Effect Postgres integration](https://orm.drizzle.team/docs/connect-effect-postgres)
- [Neon integration](https://orm.drizzle.team/docs/connect-neon)
- [Neon poolQueryViaFetch configuration](https://github.com/neondatabase/serverless/blob/main/CONFIG.md#poolqueryviafetch-boolean)

Start with the Effect Postgres and Neon integration documentation, then read @neondatabase/serverless CONFIG.md for poolQueryViaFetch and transport behavior. Compare the existing drizzle-orm/effect-postgres and drizzle-orm/neon-serverless entry points. Done means a defined Effect-native Neon API with typed failures, layers, supported HTTP/WebSocket transaction semantics, and documented cancellation limits.

Written by the indexing model from the issue text.