[BUG]: `turso://` URLs fail in drizzle-kit: it detects the user's `@tursodatabase/serverless` but runs a bundled 1.1.3 copy that lacks `turso://` normalization

### Report hasn't been filed before.

- [x] I have verified that the bug I'm about to report hasn't been filed before.

### What version of `drizzle-orm` are you using?

1.0.0-rc.4

### What version of `drizzle-kit` are you using?

1.0.0-rc.4

### Other packages

@tursodatabase/serverless@1.4.0

### Describe the Bug

**What is the undesired behavior?**

With `dialect: "turso"` and `@tursodatabase/serverless` installed, drizzle-kit fails on `turso://` URLs (the scheme the Turso Cloud dashboard now issues) with a fetch error about an unknown/unsupported scheme, while the application itself connects fine with the exact same URL through the same (installed) SDK.

**Root cause** (from reading `bin.cjs` of 1.0.0-rc.4):

drizzle-kit *checks* for the user's installed package, but then *loads its own bundled copy* of the SDK instead of importing the installed one:

```js
if (await checkPackage("@tursodatabase/serverless")) {
humanLog(withStyle.info(`Using '@tursodatabase/serverless' driver for database querying`));
const { connect } = await Promise.resolve().then(() => (init_dist$2(), dist_exports)); // ← bundled copy, not the user's install
...
const client = connect({ url: normaliseSQLiteUrl(credentials.url, "libsql") });
```

The bundled copy is pinned at **1.1.3** (region marker in `bin.cjs`):

```
//#region ../node_modules/.pnpm/@tursodatabase+serverless@1.1.3/node_modules/@tursodatabase/serverless/dist/index.js
```

and 1.1.3 only normalizes `libsql://`:

```js
return url.replace(/^libsql:\/\//, "https://");
```

whereas the installed 1.4.0 handles `turso://` as well:

```js
return url.replace(/^(libsql|turso):\/\//, "https://").replace(/\/+$/, "");
```

drizzle-kit's own `normaliseSQLiteUrl(url, "libsql")` passes any URL that has a protocol through unchanged, so the raw `turso://` URL reaches the bundled 1.1.3 `connect()` and the underlying `fetch` rejects the scheme.

Note the asymmetry: the `@libsql/client` code path does a real `await import("@libsql/client")` of the user's installed package, but the `@tursodatabase/serverless` path uses the bundled snapshot. So `checkPackage` gates on a package whose version can be (and here, is) newer than the code that actually runs — the CLI even logs `Using '@tursodatabase/serverless' driver`, which makes the failure very hard to debug.

**What are the steps to reproduce it?**

1. `pnpm add drizzle-orm@1.0.0-rc.4 drizzle-kit@1.0.0-rc.4 @tursodatabase/serverless@1.4.0` (no `@libsql/client` anywhere in the tree)
2. `drizzle.config.ts` with `dialect: "turso"`, `url: "turso://.turso.io"`, `authToken: ""`
3. Verify the app / a plain script connects fine: `connect({ url: "turso://.turso.io", authToken })` from the installed 1.4.0 works (it normalizes the scheme internally)
4. `npx drizzle-kit push` (or `migrate`) → fetch fails on the `turso://` scheme

**What is the desired result?**

- Import the user's installed `@tursodatabase/serverless` (consistent with the `@libsql/client` path), or keep the bundled copy up to date, **or**
- Normalize `turso://` → `https://` in `normaliseSQLiteUrl` for the turso dialect, which would make the URL work regardless of driver version

**Workaround** for anyone hitting this: normalize the scheme in `drizzle.config.ts`:

```ts
const url = process.env.TURSO_DATABASE_URL.replace(/^turso:\/\//, "https://");
```

Related: #6163 (driver precedence: a leftover transitive `@libsql/client` in the dependency tree shadows this driver entirely)

**Environment**: pnpm 10 workspace / monorepo, Node.js 22, macOS & Linux (CI), Turso Cloud (remote database).

Start by reproducing the failure with drizzle-kit 1.0.0-rc.4, the Turso dialect, and a turso:// URL, then inspect the driver-loading section and normaliseSQLiteUrl in bin.cjs. Compare that path with the installed @tursodatabase/serverless and the @libsql/client import path; done means the reported Turso configuration works without the workaround.

Written by the indexing model from the issue text.