[BUG]: drizzle-kit's tsconfig path-alias resolver does not follow "extends"

### 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.1

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

1.0.0-rc.1

### Other packages

_No response_

### Describe the Bug

drizzle-kit (1.0.0-rc.1) loads `compilerOptions.paths` from the `tsconfig.json` in the directory where the schema lives, but does **not** follow `"extends"`. In a monorepo where the root `tsconfig.base.json` defines `paths` and per-package `tsconfig.json` only does `{ "extends": "../../tsconfig.base.json" }`, drizzle-kit sees no aliases and falls back to literal path resolution, producing nonsensical paths like:

```
Cannot find module '/repo/packages/auth/packages/auth/src/database/schema/index'
```

(the `@packages/auth/...` alias is treated as a relative path under the package directory).

`tsc --build`, vitest (via `vite-tsconfig-paths`), and bun's TS loader all resolve the alias correctly because they follow `extends`.

This breaks `drizzle-kit generate`, `drizzle-kit studio`, and any other command that has to import schema files in a workspace where `paths` is defined upstream of the package's own `tsconfig.json`.

### Repro

Monorepo layout:

```
tsconfig.base.json // { compilerOptions: { paths: { "@packages/*": ["./packages/*"] } } }
packages/foo/tsconfig.json // { "extends": "../../tsconfig.base.json" }
packages/foo/drizzle.config.ts
packages/foo/src/database/schema/a.schema.ts // imports "@packages/foo/src/database/schema/b"
packages/foo/src/database/schema/b.schema.ts
```

Run `drizzle-kit generate` (or `studio`) from `packages/foo/`:

```
Error: Cannot find module '/repo/packages/foo/packages/foo/src/database/schema/b'
```

**Workaround:** duplicate the `paths` block inline into every per-package `tsconfig.json` instead of relying on `extends`. Painful in any non-trivial monorepo.

### Source pointer

`drizzle-kit/bin.cjs`, `getAliasesForTsconfig`:

```js
const tsconfig = Ge$1(baseDir);
const tsconfigPaths = tsconfig?.config?.compilerOptions?.paths;
if (!tsconfigPaths || !tsconfig?.path) {
tsconfigAliasCache.set(baseDir, undefined);
return;
}
```

`Ge$1(baseDir)` returns only the directly-loaded tsconfig — `extends` chains aren't merged. `get-tsconfig` (npm) provides `getTsconfig(...).config` that does merge `extends`; switching to that (or to `tsconfig-paths`'s `loadConfig`) would address the bug.

### Expected behavior

`compilerOptions.paths` from any tsconfig in the `extends` chain should be honored, matching `tsc` semantics.