ci(docker): switch to registry-backed BuildKit cache (GHCR)

[georgeh0]

Follow-up to #138 / #139. The previous type=gha BuildKit cache is scoped per Git ref, so each release tag (v0.2.24, v0.2.25, …) creates a fresh cache scope and gets no reuse from earlier releases. Combined with GHA's 10 GB per-repo cache limit (which we already hit at ~10 GB before the v0.2.26 release), the cache effectively never helped consecutive releases — observed empirically: the v0.2.26 release re-installed sentence-transformers from scratch despite earlier runs having exported cache.

Summary

• Switch to type=registry cache stored as buildcache-<variant> tags on the same GHCR package — branch/tag-independent, no LRU eviction, no size cap. Standard pattern for buildx multi-arch + multi-registry publishes.
• Per-variant cache tag (buildcache-slim, buildcache-full) so the two image variants don't evict each other's cache layers.
• mode=max continues to export intermediate layers (needed so the heavy stage 1 RUN uv pip install sentence-transformers layer is cached and reused).

Operational impact

• Two extra tags will appear under the cocoindex-io/cocoindex-code GHCR package — :buildcache-slim, :buildcache-full. They aren't intended for docker pull; safe to mark as private or simply ignore in package listing.
• I've already cleaned up 23 orphaned GHA cache entries on the deleted g/docker-layer-cache-v2 branch (~3.4 GB freed). Remaining v0.2.26-scoped GHA caches will age out naturally (7-day TTL, or when GHA evicts them under pressure).

Test plan

• A workflow_dispatch with test_docker=true after this lands will populate the :buildcache-* tags.
• The next real release (or another dispatch) should hit cache — Build & push step should be dramatically shorter than the v0.2.26 cold run (~10 min → ~2 min hopefully, since the heavy ST install layer reuses).

🤖 Generated with Claude Code