docker base image for faster builds

[stephen-derosa]

Breakout Dockerfile into .base and .sdk docker files. They build the base and sdk respectively.

[Copilot]

Pull request overview

This PR introduces a split Docker build (base image + SDK image) to improve build times via better layer caching, and adds GitHub Actions workflows to publish and validate multi-arch Docker images on main.

Changes:

• Add docker/Dockerfile.sdk and refactor docker/Dockerfile.base to be a reusable build-deps base layer.
• Add workflows to publish multi-arch base/SDK images to GHCR and validate the published SDK image by building cpp-example-collection.
• Update the existing CI workflow to build using the new base+SDK Dockerfiles on pull requests.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
docker/Dockerfile.sdk	New Dockerfile that builds & installs the SDK on top of a prebuilt base image.
docker/Dockerfile.base	Removes SDK build steps to make this a reusable dependency base image.
.github/workflows/docker-images.yml	New workflow to build/push base + SDK images and publish multi-arch manifests.
.github/workflows/docker-validate.yml	New workflow to validate the published SDK image after docker-images completes.
.github/workflows/builds.yml	Updates PR CI to build using the new base+SDK Docker image flow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The change-detection glob patterns only match single-level paths (e.g., include/*), but this repo has nested paths like include/livekit/... and src/tests/.... As written, sdk_changed can remain false even when relevant files change, causing the workflow to conclude successfully without publishing an image (and then downstream validation/pulls will fail). Consider switching to prefix checks (e.g., [[ "$path" == include/* ]] with globstar, or case patterns like include/**|src/**|... after shopt -s globstar) so nested paths are handled.

Suggested change

	docker/Dockerfile.sdk|src/*|include/*|bridge/*|client-sdk-rust/*|cmake/*|data/*|CMakeLists.txt|build.sh|build.cmd|build.h.in|CMakePresets.json)
	docker/Dockerfile.sdk|src/*|src/*/*|include/*|include/*/*|bridge/*|bridge/*/*|client-sdk-rust/*|client-sdk-rust/*/*|cmake/*|cmake/*/*|data/*|data/*/*|CMakeLists.txt|build.sh|build.cmd|build.h.in|CMakePresets.json)

[Copilot]

This workflow only builds/publishes images when the Dockerfile or selected inputs change, and there is no scheduled rebuild. That means the published base image may go stale and miss upstream security updates from ubuntu:22.04 and apt packages. Consider adding a schedule trigger (and/or workflow_dispatch) that periodically rebuilds at least the base image so consumers get patched dependencies.

[Copilot]

docker/Dockerfile.base relies on the BuildKit-provided TARGETARCH ARG to download the correct CMake installer. This job switched from docker buildx build --platform ... to plain docker build without explicitly setting TARGETARCH, which can be empty if BuildKit isn't enabled, leading to an invalid CMake download URL and a failing CI build. Consider using docker buildx build --platform linux/amd64 --load again, or explicitly providing --build-arg TARGETARCH=amd64 (or computing the arch inside the Dockerfile via dpkg --print-architecture).

Suggested change

	docker build \
	docker build \
	--build-arg TARGETARCH=amd64 \

[Copilot]

Same issue as the x64 job: docker/Dockerfile.base expects TARGETARCH to be set for the CMake download logic, but this uses plain docker build and doesn't pass TARGETARCH. If BuildKit isn't enabled on the runner, TARGETARCH will be empty and the build will fail. Consider using docker buildx build --platform linux/arm64 --load or passing --build-arg TARGETARCH=arm64.

Suggested change

	docker build \
	docker build \
	--build-arg TARGETARCH=arm64 \