sabtable: take vgi-rpc through vgi's re-export, never a direct dependency

The fixture no longer compiled: 32 errors, every one E0053/E0277 of the form
`expected vgi::RpcError, found vgi_rpc::RpcError`. Nothing in the trait API
had moved; the crate graph held two vgi-rpcs. sabtable required vgi-rpc
0.23.0 directly and patched crates.io to the sibling vgi-rpc-rust checkout,
while vgi-rust v0.35.0 wants 0.25.0 from crates.io. 0.x minors never unify,
so Cargo resolved 0.23.3 beside vgi's 0.25.0 and no trait impl could match.
The same failure was fixed by a version bump in c8247f7 and came back at the
next SDK minor.

vgi re-exports the crate (`vgi::vgi_rpc`, `vgi::{Result, RpcError}`)
precisely so a worker never names its version, so the fixture now imports
from there and drops both the direct dependency and the [patch.crates-io].
vgi-rust itself resolves vgi-rpc from crates.io (its workspace keeps any
local-checkout patch uncommitted), and the patch made this crate build
against whatever branch a sibling vgi-rpc-rust happened to be on — or, on a
0.26.0 checkout, not apply at all. vgi-rpc now resolves exactly once, to
the registry 0.25.0 that vgi-rust's own lockfile pins.

Also gates the BooleanArray/Float64Array import on emscripten, where the
browser fixtures that use it live, which clears the native build's only
warning.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: rustyconover

test/support/sabtable/Cargo.lock

@@ -20,23 +20,20 @@ path = "src/lib.rs"
 # (tokio); the worker falls back to the zero-dep FsStorage backend, so the native
 # staticlib builds with no heavy/C deps.
 vgi = { path = "../../../../vgi-rust/vgi", default-features = false }
-# Must match the exact vgi-rpc that `vgi` resolves to (the local checkout via
-# the [patch.crates-io] below) so the `OutputCollector` /
-# `Result` / `RpcError` types are one crate instance, not two. A stale version
-# requirement here silently resolves a SECOND vgi-rpc from crates.io and the
-# build fails on mismatched `RpcError`/`TableProducer` types.
-# Still default-features = false: no `http`, so no axum/tokio/zstd. `vgi` pulls
-# in `crypto` (AEAD split tokens, server-stack-free) via feature unification.
-vgi-rpc = { version = "0.23.0", default-features = false, features = ["macros", "stream-codec"] }
+# No direct `vgi-rpc` dependency: the trait signatures name vgi-rpc's
+# `Result`/`RpcError`/`OutputCollector`, and `vgi` re-exports that crate
+# (`vgi::vgi_rpc`, `vgi::{Result, RpcError}`) so a worker never names its
+# version. A direct requirement here is how this fixture broke twice: whenever it
+# lagged the SDK's vgi-rpc minor (0.x minors never unify), Cargo resolved a
+# SECOND vgi-rpc beside vgi's and every trait impl failed with E0053
+# (`expected vgi::RpcError, found vgi_rpc::RpcError`).
 arrow-array = "59"
 arrow-schema = "59"
 serde = { version = "1", features = ["derive"] }
 
 [profile.release]
 opt-level = 2
 
-# vgi (via ../../../../vgi-rust) resolves vgi-rpc to the local checkout;
-# point this standalone crate at the same source so both unify to ONE vgi-rpc
-# instance.
-[patch.crates-io]
-vgi-rpc = { path = "../../../../vgi-rpc-rust/vgi-rpc" }
+# No [patch.crates-io]: vgi-rust resolves vgi-rpc from crates.io (its workspace
+# keeps any local-checkout patch uncommitted), so this crate resolves it the same
+# way rather than against whatever branch a sibling vgi-rpc-rust checkout is on.

test/support/sabtable/Cargo.toml

@@ -13,15 +13,21 @@ use std::time::Duration;
 
 use arrow_array::cast::AsArray;
 use arrow_array::types::Int64Type;
-use arrow_array::{Array, ArrayRef, BooleanArray, Float64Array, Int64Array, RecordBatch, StringArray};
+use arrow_array::{Array, ArrayRef, Int64Array, RecordBatch, StringArray};
+// Only the emscripten-only browser fixtures build these column types.
+#[cfg(target_os = "emscripten")]
+use arrow_array::{BooleanArray, Float64Array};
 use arrow_schema::{DataType, Field, Schema, SchemaRef};
 
 use vgi::aggregate::{AggregateBindParams, AggregateFunction};
 use vgi::cache_control::CacheControl;
 use vgi::function::{ArgSpec, BindParams, BindResponse, FunctionMetadata, ProcessParams, ScalarFunction};
 use vgi::table_function::{TableFunction, TableProducer};
 use vgi::table_in_out::{project_batch, TableInOutFunction};
-use vgi_rpc::{OutputCollector, Result, RpcError};
+// Through vgi's re-export, never a direct vgi-rpc dependency: this is always
+// the vgi-rpc the traits were compiled against (see Cargo.toml).
+use vgi::vgi_rpc::OutputCollector;
+use vgi::{Result, RpcError};
 
 // Worker-side ring ops, implemented in C++ (test/support/vgi_sab_native_ring.cpp)
 // natively, or in the browser worker module's --js-library (vgi_worker_lib.js).