mz873: hash composite cache keys recursively

[mzihlmann]

Fixes #873

The composite cache key was the hash of all key parts joined with '-'. Because '-' is legal inside the parts, distinct part sequences can join to the same string and collide, at which point one build serves another build's cached layer. The collision does not even need two builds: Dockerfile_test_issue_mz873 makes two sibling stages collide within a single build. Stage one's single RUN spells out the joined key text of stage two's two RUNs, with a '#' turning the spelled-out tail into a shell comment. On main both commands key at the same value, both push their layer to the same tag, and the warm build serves the swapped layers, /one and /two silently exchange content between the cold and the warm build.

Behind the new FF_KANIKO_ROLLING_CACHE_KEY flag the composite cache folds every part into a fixed-size rolling state, state' = SHA256(state || part), and the state is the canonical key. The state has a fixed length, so the boundary to the next part is unambiguous and the collision class is gone. A chain prefix becomes a resumable state, which FROM-child seeding and the redirect pointer use, so the pointer no longer serializes the unbounded key text into an image label. The human readable key trail is kept for the cache-miss debug logs only. The flag defaults to off and off is byte-compatible with today's keys, switching it changes every cache key and rebuilds once, documented in the README.

The standard TestCache run of Dockerfile_test_issue_mz873 pins the fix: on main it fails with a content mismatch between the cold and the warm build, with the flag it passes. The integration suite and the golden suite run with the flag on.

[codecov]

Codecov Report

❌ Patch coverage is 75.00000% with 8 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/executor/composite_cache.go	69.23%	4 Missing and 4 partials ⚠️

📢 Thoughts on this report? Let us know!