Propagate same-run parent images to child builds via OCI artifacts - #578

Child images (e.g. webdevops/php-nginx:8.4) build FROM webdevops/php:8.4 which, outside of master, resolves to the last published Docker Hub image — not the parent image just built and tested in the same workflow run. PR changes to a parent image therefore never reach its children's tests.

CI generator (ci/src/)

• GithubCommand::traverse() now passes hasChildren (via Node::hasChildren()) to the job builder, so it knows without recomputing the graph.
• GithubJobBuilder gained small helpers — hasInternalParent, getCiImageArtifactName, getCiImagePath, parentBuildContext, buildPushWith — replacing inline string concatenation.

Parent jobs (nodes with children)

• On non-master refs only, export the built image as an OCI layout (type=oci,tar=false, reusing cache-from: type=gha so it's effectively cache-only) and upload it with actions/upload-artifact, named per image+tag+arch:

docker-parent-php_8-4-${{ matrix.arch }}

• 1-day retention, no compression (OCI layers are already compressed).

Child jobs (nodes with an internal parent)

• Download the matching-arch parent artifact and add a second docker/build-push-action invocation with a named build context mapping the exact FROM reference to the downloaded layout:

build-contexts: 'webdevops/php:8.4=oci-layout://${{ runner.temp }}/ci-oci-image/php_8-4:ci-parent-image'

• The original (master) build step is untouched; the override only applies if: github.ref != 'refs/heads/master'.
• needs now explicitly includes both the parent build and parent publish jobs ([php_8-4, php_8-4_publish]) instead of just _publish, so children wait on the real build while still running when publish is skipped (non-master) via the existing !failure() && !cancelled() guard.

Artifact names/paths are keyed by image+tag+architecture, so amd64/arm64 and different images/tags never collide, and deep chains (php → php-nginx → php-nginx-dev) each consume their direct parent's artifact only.

No registry write permissions, secrets, or pull_request_target are involved — propagation is entirely via workflow artifacts, so it works for fork PRs. Master's publish flow is unchanged.

.github/workflows/build.yaml is regenerated via ci/console github:generate-ci to match.