sea-napi-binding: relocate Rust source to kernel workspace

Per D-006 architectural decision (Python team's workspace pattern):
all language bindings (PyO3, napi-rs) now live as workspace siblings
in the kernel repo at databricks-sql-kernel/{pyo3,napi}/.

What this commit removes from the nodejs repo:
- native/sea/Cargo.toml (path dep relocated; package now at
  databricks-sql-kernel/napi/Cargo.toml with path = "..")
- native/sea/build.rs
- native/sea/src/* (lib, runtime, database, connection, statement,
  result, error, logger, util — all 9 files)
- native/sea/package.json (the @databricks/sea-native-linux-x64-gnu
  sub-package moves to the kernel workspace too)
- native/sea/index.js (regenerated artifact)

What stays in nodejs:
- native/sea/index.d.ts — TS declarations consumed by lib/sea/ adapter
- native/sea/README.md (new) — explains the move; points readers at
  databricks-sql-kernel/napi/

What's updated:
- package.json: `build:native` and `build:native:debug` scripts now
  delegate to the kernel workspace via $DATABRICKS_SQL_KERNEL_REPO
  (defaults to ../../databricks-sql-kernel-sea-WT/napi-binding for the
  local dev worktree layout). Build copies index.node + index.d.ts
  back into native/sea/ for the loader to find.

Why workspace co-location:
- Arrow version pinning lockstep — no silent IPC version drift
- path = ".." (clean) vs ../../../../databricks-sql-kernel-sea-WT/...
- Single CI: cargo build --workspace covers kernel + pyo3 + napi
- Kernel API changes that break either binding caught at PR-review time
- Future cgo binding for Go SEA slots in as another workspace member

This branch (sea-napi-binding) is now a thin consumer of the kernel
napi crate. The actual Rust code lives at krn-napi-binding HEAD on
the kernel repo (commit debe3d7).

Author: msrathore-db

native/sea/.gitignore

@@ -0,0 +1,41 @@
+# `native/sea/` — consumer-side directory for the Rust napi binding
+
+**The Rust binding source lives in the kernel repo** at
+`databricks-sql-kernel/napi/`, as a workspace sibling of `pyo3/`.
+See `databricks-sql-kernel`'s root `Cargo.toml` `[workspace] members`.
+
+## Why
+
+Per the architectural decision recorded in
+`sea-workflow/decisions.md` (D-006), every language binding (PyO3,
+napi-rs, future cgo) is a workspace member of the kernel crate. This
+keeps Arrow version pinning lockstep, the path dep clean (`path = ".."`),
+and CI single (`cargo build --workspace`). The pattern matches polars,
+ruff, arrow-rs.
+
+## What lives here
+
+- `index.d.ts` — generated TypeScript declarations consumed by `lib/sea/`
+- `index.linux-x64-gnu.node` (and other platform variants) — symlinked
+  or copied build artifacts from the kernel workspace at run time
+
+## How to build the binding for local dev
+
+```bash
+# From the nodejs repo root:
+npm run build:native
+# which delegates to the kernel workspace:
+#   cd $DATABRICKS_SQL_KERNEL_REPO/napi && napi build --release
+# and copies the artifact back here
+```
+
+`$DATABRICKS_SQL_KERNEL_REPO` defaults to a path published with the
+release flow; for dev it points at a local checkout of
+`databricks-sql-kernel`.
+
+## How to consume in production
+
+At release time the kernel CI publishes `@databricks/sea-native-<triple>`
+npm packages with the `.node` binaries. The nodejs driver declares them
+as `optionalDependencies` in `package.json`; `SeaNativeLoader.ts`
+resolves the right one at runtime.