Optimize Docker build workflows

[falcorocks]

Optimize Docker build workflows

Summary

The GitHub Actions Docker build workflows build all images on every qualifying commit, regardless of which files actually changed. For PRs that only touch a single service, this wastes significant CI time building ~18 unaffected images. Additionally, the workflow structure leads to a confusing PR experience and maintenance burden due to duplicated configuration.

Problems

1. No per-image change detection

The branches.yaml workflow has coarse paths filters (e.g. ops/docker/**, packages/contracts-bedrock/**) but once triggered, it builds every image in the matrix. A PR that only modifies op-node code will still build op-batcher, cannon, kona-node, and 15 other images.

PRs should only build affected images. When a PR touches code for a single service, only that service's image should be built. Changes to shared infrastructure (the Dockerfile, docker-bake.hcl, ops/docker/, etc.) should still trigger all builds. Scheduled builds should continue to build all images.

2. Confusing fork/local branch job visibility

The workflow uses mutually exclusive if conditions to split builds between local branches and fork PRs. On any given PR, one set of jobs always runs and the other is always skipped — but both sets are displayed in the GitHub checks UI. This means contributors see ~18 skipped jobs alongside ~18 running jobs, making it hard to find the actual results.

Contributors should only see relevant jobs — not a wall of skipped jobs for the build path that doesn't apply to their PR. The fork/local security model must be preserved: images built from local branches are pushed to the registry, while fork builds must never push to the registry.

3. Duplicated image matrix

The image list is repeated four times in branches.yaml: build, build-fork, check-cross-platform, and check-cross-platform-rust. Adding or removing an image requires updating all four locations, which is error-prone.

The set of images to build should be maintained in a single location, not duplicated across multiple jobs.

Acceptance Criteria

• PRs that only affect a single service build only that service's image (plus any images affected by shared code changes).
• Contributors don't see skipped jobs for the other build path (fork vs. local).
• The image list is defined in a single location within the workflow configuration.
• Scheduled builds continue to build all images.
• The existing security model is preserved: fork PRs never push images to the registry.
• Builds continue to use the reusable factory docker workflow.