ci: no CI job builds or tests the vendored RocksDB engine

[gustavovalverde]

Motivation

Zebra's CI never builds or tests against the RocksDB engine that Zebra actually ships to users.

.github/actions/setup-zebra-build/action.yml always sets ROCKSDB_LIB_DIR=/usr/lib/ and installs librocksdb-dev from the Ubuntu apt repo, so lint, unit-tests, and test-crates all link zebra-state against the distro's system RocksDB package instead of the vendored version pinned by librocksdb-sys.

The vendored version only gets built at all in zfnd-release-binaries.yml, which is workflow_call-only (release time only) and only builds the binary; it doesn't run any test suite. So no CI job compiles the vendored engine and runs tests against it, and no job validates that a finalized state written by one RocksDB version still opens correctly under another.

This gap surfaced during review of #10922 (rocksdb 0.22 -> 0.24, vendored RocksDB 8.10.0 -> 10.4.2): CI was green, but nothing in the automatic PR checks actually exercised the version being upgraded to, or confirmed that an existing database written by the old version opens correctly under the new one.

Solution

• Add a CI job that leaves ROCKSDB_LIB_DIR unset so librocksdb-sys builds the vendored RocksDB from source, and run at least cargo test -p zebra-state against it. A single dedicated job is enough; it doesn't need to be added to the whole build matrix.
• For RocksDB version bumps specifically, validate opening an existing finalized state (for example one of the GCP cached mainnet disks) with the vendored engine before merging, to catch on-disk format incompatibilities between RocksDB versions.

Related

• build: update rocksdb to 0.24 #10922