[FEATURE]: Native Effect v4 support for @tursodatabase/database (effect-tursodatabase) in v1

### Feature hasn't been suggested before.

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

### Summary

`drizzle-orm@1.0.0-rc.4` shipped native **Effect v4** integration — but only for these entrypoints: `effect-libsql`, `effect-sqlite-bun`, `effect-sqlite-node`, `effect-sqlite-do`, `effect-sqlite-wasm`, `effect-d1`, `effect-postgres`, `effect-pglite`, `effect-mysql2`.

The Rust **Turso** engine (`@tursodatabase/database`, plus `@tursodatabase/serverless` and `@tursodatabase/sync`) only got the **regular async** driver `drizzle-orm/tursodatabase`. There is no `drizzle-orm/effect-tursodatabase`.

This is a follow-up to the now-landed Effect v4 work tracked in #5414 — that issue covered the general "should Drizzle target Effect v4" question (resolved), but the Rust Turso engine was left out of the Effect-native driver set. This request is specifically to close that gap.

### What exists today in rc.4

- `drizzle-orm/tursodatabase` — async driver over the Rust Turso engine (Promises).
- `drizzle-orm/effect-libsql` — Effect-native driver over the C **libSQL** fork (queries as `Effect`, connection as a `Layer`, typed `SqlError`).

### What's missing

A `drizzle-orm/effect-tursodatabase` entrypoint at **parity with `effect-libsql`**, most likely built on a new `@effect/sql-tursodatabase` client:

- queries that return `Effect` instead of `Promise`
- the connection exposed as a composable `Layer`
- a typed `SqlError`
- interruption + OpenTelemetry tracing wired in, consistent with the rest of an Effect codebase

Ideally also Effect variants for `tursodatabase-serverless` and `tursodatabase-sync`.

### Use case

We're building a multi-agent "agent OS" where many autonomous agents **write concurrently** to a shared task graph stored in an in-process SQLite-compatible DB. Our stack is **Bun + Effect v4 + Drizzle over SQLite**, with Effect as the default for all backend logic (typed errors, Layers/DI, structured concurrency, interruption, Schedule-based retry, OpenTelemetry).

We specifically want the **Rust Turso engine** (not the C libSQL fork) because of:

- **`BEGIN CONCURRENT` / MVCC concurrent writes** — multiple agents writing the task graph without single-writer contention. libSQL keeps SQLite's single-writer model, so it doesn't solve this; the Rust engine does.
- **CDC (change data capture)** — to drive event-based orchestration.

So the two Effect-native paths that exist (`effect-libsql`, `effect-sqlite-*`) don't cover our case: they're either single-writer libSQL or plain SQLite. The driver that fits (`tursodatabase`) is the only one without an Effect-native variant — forcing a choice between "real Rust Turso (no Effect-native)" and "Effect-native (only libSQL / plain SQLite)". We'd like both.

### Why it matters for Effect users

Without `effect-tursodatabase`, Effect users adopting the Rust Turso engine have to hand-roll the Effect seam over the async driver: wrap every call in `Effect.tryPromise`, define a bespoke tagged error, and manage the connection via `Effect.acquireRelease`. That bespoke glue loses the interruptibility, typed-error, and observability integration that the first-party `effect-*` drivers provide — and it diverges from the rest of an Effect codebase. The whole value of the native drivers is that this is done once, correctly, upstream.

### Proposed API (parity with `effect-libsql`)

```ts
import { TursoClient } from "@effect/sql-tursodatabase"; // proposed
import * as TursoDrizzle from "drizzle-orm/effect-tursodatabase"; // proposed, parity with effect-libsql
import { Effect } from "effect";

const ClientLive = TursoClient.layer({ url: "file:local.db" });

const program = Effect.gen(function* () {
const db = yield* TursoDrizzle.make({ schema });
const rows = yield* db.select().from(tasks); // returns an Effect, typed SqlError, interruptible
}).pipe(Effect.provide(ClientLive));
```

### Timing

Since the rest of the Effect-native driver matrix landed in `1.0.0-rc.4`, it'd be ideal to include `effect-tursodatabase` in the **v1** release rather than leaving the Rust Turso engine as the one major driver without an Effect-native variant. We'd adopt `@tursodatabase/database` as our primary store the day this entrypoint exists — today the missing entrypoint is the only blocker.

Start by comparing the existing drizzle-orm/effect-libsql and drizzle-orm/tursodatabase entrypoints, then review the proposed @effect/sql-tursodatabase client boundary. Done means an effect-tursodatabase entrypoint reaches parity with effect-libsql: Effect-based queries, a composable Layer, typed SqlError, interruption, and OpenTelemetry tracing; serverless and sync variants are optional goals.

Written by the indexing model from the issue text.