Store RHEL8 image layer cache in GHCR instead of the Actions cache

[magnesj]

The nightly "Build RHEL8 CI Image" workflow has failed every night since 2026-07-23 (on both OPM/ResInsight and forks) with:

#23 exporting to GitHub Actions Cache
#23 ERROR: not_found
ERROR: failed to build: failed to solve: not_found

The image itself builds and pushes to GHCR successfully — only the final cache-to: type=gha,mode=max export fails, marking the run red.

Root cause: the repository's Actions cache is at the 10 GB per-repo limit (10.4 GB on OPM/ResInsight), shared with all other workflows. The multi-GB BuildKit export is evicted as fast as it is written, which both breaks the export commit (not_found) and makes restores useless — the build log shows a 0% cache hit rate, so every nightly run did the full cold compile.

Changes:

• Registry layer cache instead of the Actions cache. The BuildKit cache now lives in GHCR (ci-rhel8:buildcache), which has no size cap. The existing ${GITHUB_REPOSITORY,,} image-name pattern makes this work unchanged on upstream and forks. The buildcache tag is excluded from the daily image-version cleanup, alongside latest.
• The vcpkg stage is keyed on its actual inputs. It previously copied the entire build context before compiling the dependencies, so any source commit invalidated the layer and every nightly build recompiled all vcpkg ports (~1 h). It now copies only vcpkg.json, the vcpkg configuration and the vcpkg tool, and runs a direct manifest install.
• .git is excluded from the Docker build context. Its internals differ between checkouts of the same commit, which silently invalidated COPY . /src on every run. The in-image build does not need it (the CMake submodule init is guarded by EXISTS .git).

Verified on magnesj/ResInsight:

• Cold run (2h24m): builds 101 vcpkg packages, exports the cache to GHCR without errors; the warmup configure logs Restored 101 package(s) from /opt/vcpkg-cache, confirming the ABI hashes from the direct manifest install match the CMake-driven configure.
• Run after a source-only change (1h20m): the entire vcpkg-builder stage is CACHED from the registry cache; only the build-warmup stage recompiles. This is the nightly scenario — the ~1 h vcpkg portion is eliminated and the cache export no longer fails.