ci: bump VGI_REF to HEAD after upstream rename batch

The integration suite pins the .test files at VGI_REF but installs the vgi
extension live from community (unpinned). Upstream advanced past the old pin
(4444d66) with extension-side renames the community build already shipped, so
the pinned tests called names the new extension no longer has:

  vgi_join_keys_limit setting    -> vgi_join_keys_threshold (0504226)
  vgi_worker_subprocess_pool()   -> vgi_worker_pool()       (8381b69)
  vgi_worker_pool_flush() scalar -> table function          (f9e78f5)

All are SQL surface, not worker code — no Java change needed. Bumping VGI_REF
to HEAD (3e4b68d) picks up the updated tests. HEAD also adds
connection_string.test (bare connection-string / ?location= ATTACH discovery),
which reuses the existing InvokeCatalogs RPC, so the worker already satisfies
it. Verified the full source-built suite (185/185) and re-ran the four renamed
tests + connection_string.test against the actual CI path (INSTALL vgi FROM
community + local haybarn-unittest + the Java worker) — all green.

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

Author: rustyconover

.github/workflows/integration.yml

@@ -28,7 +28,7 @@ env:
   # The Query-farm/vgi commit whose test/sql/integration suite we run. Pinned
   # for reproducibility; bump deliberately and re-validate against the then-current
   # community extension (see ci/README.md).
-  VGI_REF: 4444d669c700d9efd70e5f97db4d2c4c886f509f
+  VGI_REF: 3e4b68da081cae8215018221092e2408f100766a
   # The Haybarn release providing the prebuilt haybarn-unittest binary. Must be
   # ABI-compatible with the community-published vgi extension (both v1.5.3).
   HAYBARN_RELEASE: haybarn-v1.5.3-rc7

CLAUDE.md

@@ -287,6 +287,32 @@ older interfaces** (`TableFunction`, `TableInOutFunction`, etc.) — the
 `ScalarFn` style hasn't been extended to those because their richer
 lifecycle methods + per-execution state don't translate one-for-one.
 
+## State of play (as of 2026-06-15)
+
+**2026-06-15 — re-greened CI after an upstream rename batch + bumped `VGI_REF`
+to HEAD (`3e4b68d`).** CI went red because the suite pins the `.test` files at
+`VGI_REF` but installs the `vgi` extension **live from community** (unpinned).
+Upstream advanced past the old pin (`4444d66`) with a cluster of rename commits
+that the community extension had already shipped, so the old tests called names
+the new extension no longer had:
+- `vgi_join_keys_limit` setting → `vgi_join_keys_threshold` (`0504226`)
+- `vgi_worker_subprocess_pool()` → `vgi_worker_pool()` (`8381b69`)
+- `vgi_worker_pool_flush()` scalar → **table** function (`f9e78f5`)
+
+All three are **extension-side SQL surface, not worker code** — no Java change
+was needed; the failures were stale pinned tests. Fix = bump `VGI_REF` to HEAD
+(`integration.yml`). HEAD also adds **`connection_string.test`** (bare
+connection-string / `?location=` ATTACH discovery, `e19e189`/`15fe529`); that
+feature **reuses the existing InvokeCatalogs RPC**, so the worker already
+satisfies it with no port. Verified the full source-built suite (185/185) *and*
+re-ran the four renamed tests + `connection_string.test` against the **actual CI
+path** — `INSTALL vgi FROM community` driving the local `haybarn-unittest` (the
+homebrew `/opt/homebrew/bin/haybarn-unittest`) + the Java worker — all green,
+proving the community build already carries the connection-string feature (the
+risk that gated bumping straight to HEAD). `HAYBARN_RELEASE` left at `rc7`
+(upstream's `rc10` bump is a Windows-MSVC build fix, not a runtime-ABI change;
+rc7 still passes against the current community extension).
+
 ## State of play (as of 2026-06-12)
 
 **2026-06-12 — HTTP table-function streaming sweep (state serialization).** The