Build/rebar3 caches serve stale git-branch plugins (audit ran old rebar3_audit after fix merged)

[Taure]

Problem

When a consumer pins a plugin/dep by branch (e.g. asobi_site: {rebar3_audit, {git, "...", {branch, "main"}}}), the erlang-ci caches keep serving the old compiled artifact after upstream main advances, because the cache keys don't reflect the branch's current commit:

• erlang-ci-build-* key hashes rebar.config/lock, but a {branch, main} ref is textually stable, so the key never changes.
• erlang-ci-rebar3-* caches ~/.cache/rebar3 (where plugins are installed); rebar3 reuses the cached branch checkout without re-pulling.

Observed

After merging the rebar3_audit pagination fix (Taure/rebar3_audit#16) to main, asobi_site's Audit job still ran the old looping code and hit the 300s timeout - twice. It only picked up the fix after manually deleting all erlang-ci-* caches (build + rebar3), forcing a fresh clone. Audit then passed in 20s.

Fix options

1. Include resolved branch-dep commit SHAs in the cache key (hash rebar.lock plus the current HEAD of any {branch, _} dep/plugin), so a branch advance busts the cache.
2. Or rebar3 unlock/refresh branch deps before build in the setup action.
3. Or document + nudge consumers to pin plugins to tags (honest cache key, reproducible) - relates to the pinning conventions already in use.

Related: same class as the nightly stale-cache issue (test-profile deps not in rebar.lock). Surfaced via #65 / #66 (audit timeout) and rebar3_audit#16 (the fix that couldn't reach CI).

[Taure]

Root cause sharpened while mitigating: the stale artifact is a plugin (rebar3_audit), and rebar3 does not record plugins in rebar.lock — only regular deps. So a {branch, main} plugin has no committed SHA anywhere, which means no cache-key strategy based on hashing rebar.config/rebar.lock can ever invalidate it when the branch advances. That's why deleting the caches was the only thing that worked.

Two durable fixes:

1. Consumer-side (applied): pin branch plugins to an immutable ref. Done for asobi_site — pinned rebar3_audit to v0.2.7 (chore: pin rebar3_audit to v0.2.7, bump erlang-ci to v2.1.2 widgrensit/asobi_site#85). Keeps the cache key honest and the build reproducible; matches the "pin + bump-downstream" convention.
2. erlang-ci-side (still open, the general fix): for consumers that legitimately track a branch plugin, the setup step would need to force-refresh git-branch plugins each run (e.g. drop the cached checkout before build) since lock-hashing can't help. This is the durable class fix; leaving Build/rebar3 caches serve stale git-branch plugins (audit ran old rebar3_audit after fix merged) #67 open to track it. Lower urgency now that the incident path is pinned.