fix: link vcpkg static libroaring by exact path

[GavinPizza]

Problem

The build installs and pins CRoaring 4.7.2 through vcpkg manifest mode, then does not reliably link it. pgxs puts -L/usr/lib ahead of the vcpkg -L, so -lroaring resolves against whatever system CRoaring the host happens to have. Which library ends up inside the extension is a property of the machine, which is what pinning is meant to remove.

Where a system copy exists and is old, the build looks clean and the extension will not load.
Debian bookworm ships 0.2.66, which does not export roaring_free:

ERROR:  could not load library ".../pg_ducklake.so":
        .../pg_ducklake.so: undefined symbol: roaring_free

The link still exits 0 and produces the .so, because a shared object may carry undefined symbols. Nothing fails until dlopen, so any check that builds without loading passes it straight through.

CI is unaffected today because its images carry no system CRoaring. That is luck rather than construction, since nothing asserts it. If a base image or a new apt dependency ever pulls one in, the build silently changes which CRoaring it links, with no signal.

Fix

Link $(ROARING_LIB_DIR)/libroaring.a by full path when it is set, so search order cannot override it. Fall back to -lroaring when unset, unchanged, for builds that intend a system copy.

Testing

Both arms on this branch, on Debian with libroaring 0.2.66 installed.

• With the hunk: CREATE EXTENSION, LOAD, and a preloaded postmaster all succeed, a ducklake table round-trips, regression suite 52/52. The .so has no undefined roaring symbols and no DT_NEEDED on libroaring.
• Hunk reverted, same branch and host: link still exits 0, the .so records DT_NEEDED libroaring.so.0, and load fails with the error above (as FATAL when preloaded).

Verified on x64-linux only. The archive path is built from $(VCPKG_TARGET_TRIPLET), so arm64 should resolve the same way, and the Docker workflow exercises it.