chore(server/cuda): bump pinned llama.cpp digest

[github-actions]

Upstream ghcr.io/ggml-org/llama.cpp:server-cuda has moved past the digest pinned in server/Dockerfile.cuda.

	digest
pinned	sha256:7b3d7834fc7307cb54f24f8869b67bfff276404c416452a48d11321bc36a81be
current	sha256:fc26b60b30836e5a12fdb28823a3d4bda984c9386a4b04200c78e5a5150067fb

To update

1. Bump the FROM ghcr.io/ggml-org/llama.cpp:server-cuda@sha256:… digest in server/Dockerfile.cuda to sha256:fc26b60b30836e5a12fdb28823a3d4bda984c9386a4b04200c78e5a5150067fb.
2. cd server && make scout-cuda to rebuild + scan (the shared-lib layout may have changed — the Dockerfile copies all /app/*.so* to stay robust).
3. Confirm /app/llama-server still resolves all libs, then promote.

Auto-filed by the weekly llama.cpp pin freshness workflow.

[dvcdsys]

Fixed in #217 (merged to develop as 09d33df): server/Dockerfile.cuda now pins sha256:fd68d130…, which is the current :server-cuda digest — the fc26b60b this issue named had already been superseded.

The bump also required a fix outside the Dockerfile: upstream moved each tool's logic into its own libllama-<tool>-impl library, and fetch-llama.sh copied a hand-maintained file list, so the macOS bundle's llama-server aborted at dyld load with Library not loaded: @rpath/libllama-server-impl.dylib. It now ships the whole library set (as the Dockerfiles already do with COPY /app/*.so*) and fails the fetch if any @rpath dependency is missing.

Verified: CPU image builds with the new digest and /app/llama-server runs (docker scout: 0 CRITICAL / 0 HIGH); the CUDA digest carries /app/llama-server + libllama-server-impl.so and the COPY /app/*.so* glob still captures them. A full make scout-cuda still needs the amd64 builder before the next release tag.