docker: a branch *_REF is cached forever, so a long-lived builder never refreshes the addon head

[reichie020212]

Raised by @gonzalesedwin1123 as an out-of-scope observation while reviewing #507, and
kept out of that PR deliberately.

The problem

download_module in docker/Dockerfile caches tarballs on a buildkit cache mount and
re-downloads only when the cached file is missing or fails gzip -t:

RUN --mount=type=cache,target=/tmp/downloads,sharing=locked \
    ...
    local tarball="/tmp/downloads/${dest}-${ref}.tar.gz"; \
    if [ ! -f "$tarball" ] || ! gzip -t "$tarball" 2>/dev/null; then \
        rm -f "$tarball"; \
        curl -fsSL -o "$tarball" "$url"; \
    fi; \

For a sha ref that is exactly right: the content is immutable, so the cache key
${dest}-${sha}.tar.gz is sound.

For a branch ref — which is every default (*_REF=19.0) — the cache key
server-ux-19.0.tar.gz names a moving target. Once a valid tarball for it exists, the
condition is false forever, so a long-lived builder keeps building against whatever the
branch head was the first time it downloaded, indefinitely and invisibly.

Why it matters

It is the mirror image of the drift #507 addresses. #507 fixes "two builds of the same
OpenSPP commit can pick up different addon code"; this is "two builds months apart can
pick up the same, stale addon code, on a machine where the cache survives". Both
undermine the same property, and both are silent.

The spp_user_roles / base_user_role breakage seen on #507 is the same mechanism one
layer up: a GHA layer cache had held a pre-rename base_user_role since before OCA's
2026-05-18 role_ids → user_role_ids rename, so 19.0 stayed green for ~4 months
against code no fresh build would have produced.

Options

• Skip the cache for non-sha refs (only cache what is content-addressed).
• Age out branch tarballs (e.g. re-download when older than N hours).
• Leave it, and treat sha pinning as the supported reproducible path — in which case say
  so in docker/README.md, since the current text does not warn that an unpinned ref can
  also go stale rather than merely drift.

No preference expressed here; it needs a decision rather than a patch.