feat(release): affected-set — build only what changed since the last release

[elronbandel]

What

On a manual dispatch, enumerate now diffs HEAD against the previous vX.Y.Z
tag and builds only the combos + per-task images whose benchmark or agent
source changed. Everything unchanged keeps its current published image.

Why

Every dispatch rebuilt the full ~12.8k-combo fleet even when a single benchmark
changed. This is the standard affected set (Nx/Turborepo's affected), done with
a plain git diff — no content-hash tags, no per-job skip, no helper script.

Cascade + escape hatches

• A change under containers/core, containers/gateways, or the root bake is a
  shared/base change → the full fleet rebuilds (the cascade = "bulk on base update").
• rebuild_bases, --only, a tag release (vX.Y.Z push), or no prior tag all
  build the full fleet, unchanged from today.

Scope

Combos + per-task only — the bulk and the ~60-min per-task layer. Leaves stay full:
they're ~38 s cache hits, and an empty leaf matrix would skip the merge job the
combos depend on.

Verification

• Filter logic checked on a sample diff: a gsm8k + claude-code change keeps
  gsm8k/* and */claude-code combos (drops aime/codex) and only gsm8k
  per-task; a containers/core/* change skips the filter (full build).
• actionlint + yamllint green.

Supersedes #239 (the content-hash-tag approach) — git-diff is the standard and far simpler.

[elronbandel]

Closing — not a net-positive change.

• Targeted refreshes already work today via --only <benchmark> (no new code); this only auto-computed that set from a git-diff.
• Dispatch-only — a vX.Y.Z tag release still rebuilds the whole fleet, so it doesn't address the 'every release rebuilds everything' pain.
• Adds a silent-staleness risk --only doesn't have: an auto affected-set is only as correct as its path-mapping; a missed dependency = a stale image with no error.
• It's a hand-rolled nx affected patching around the N×M combo volume rather than the root question: does the cross-product need pre-baking at all (vs composing benchmark+agent at run time)?

Parking that architectural decision instead.