ci: pull the haybarn build that carries the protocol 1.3.0 extension

The integration suite deliberately runs against the published, signed vgi
extension rather than one built from source, so it only ever sees what a real
user's DuckDB would load. That makes the pinned engine release load-bearing:
haybarn extensions are ABI-locked to their engine version, so the pin decides
which vgi build the channel serves.

The C++ extension rolled to haybarn-v1.5.5-rc1 and was rebuilt for protocol
1.3.0, but this pin still named v1.5.4-rc3 — whose channel entry is the
1.2.0-era build. Every lane therefore failed with `Client: 1.2.0 / Server:
1.3.0` once vgi-python declared 1.3.0, which reads like a Python regression
and is really a stale pin.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MS3MkkHgE8pA3Aty7BnZKE

Author: rustyconover

.github/workflows/integration.yml

@@ -32,7 +32,7 @@ env:
   VGI_REF: main
   # The Haybarn release providing the prebuilt haybarn-unittest binary. Must be
   # ABI-compatible with the community-published vgi extension.
-  HAYBARN_RELEASE: haybarn-v1.5.4-rc3
+  HAYBARN_RELEASE: haybarn-v1.5.5-rc1
   # CI is not a user: its ATTACHes should not land in Query.Farm's adoption data.
   # The vgi extension fires a telemetry event per successful ATTACH, and this
   # suite performs several hundred of them per lane, so opting out keeps the