Port max-cache-size-mb to release/v2 (v2 has no cache-size bound at all)

[jox51]

main and release/v2 diverged at ab5c1da, and the two branches have disjoint cache-management features:

• main has the max-cache-size-mb input (feat: allow users to configure max cache bytes #91, Add unit to input option for max cache size #95) but no cache-key.
• release/v2 (tags v2, v2.0.0, v2.0.1, v2.1.0) has the required cache-key (feat: add required cache-key input, native GC, and server-driven config for v2 #108) but no max-cache-size-mb. pruneBuildkitCache() exists in src/setup_builder.ts:583 on that branch with no call sites outside tests, so v2 never prunes.

That leaves no way to bound Docker layer cache growth on v2:

• Pinning to main to get max-cache-size-mb means losing cache-key, i.e. going back to one shared repo-wide disk with last-write-wins across concurrent matrix builds.
• Staying on v2 means relying entirely on server-driven buildkitd GC. DEFAULT_BUILDKITD_CONFIG is gc: true with a single age-based policy (keepDuration: 192h, all: true) and no keepBytes, so even when the server doesn't disable GC the config is time-bounded, not size-bounded.

Concretely: a repo with four per-Dockerfile v2 disks accumulated ~167 GB across ~2 days, with the observed server config reporting gc: false. At $0.50/GB/mo that is real money with no user-facing lever to stop it.

Ask: wire max-cache-size-mb into release/v2 (input + a pruneBuildkitCache() call site) and cut a v2 tag, or document the supported way to bound per-key cache size on v2. I couldn't find an open PR targeting release/v2 for this — all open PRs currently target main.

Workaround in use meanwhile: a workflow_dispatch job that mounts each disk with its cache-key and runs sudo buildctl --addr tcp://127.0.0.1:1234 prune --all --keep-storage <MB> by hand.