Add multi-platform container builds for amd64 and arm64

[pditommaso]

Summary

• Add support for multi-platform container builds targeting both linux/amd64 and linux/arm64 architectures
• Multi-platform builds are triggered by specifying a multi-arch containerPlatform value (e.g. linux/amd64,linux/arm64) — the previous multiPlatform boolean flag has been removed
• Introduce ContainerPlatform.Platform inner class to properly model per-platform {os, arch, variant} tuples instead of a shared OS with a list of bare arch names
• Introduce ChildRefs value type to track per-platform child build and scan IDs with proper Moshi serialization
• Per-architecture security scanning: each platform gets its own scan ID and independent scan execution
• MultiPlatformBuildService orchestrates parallel per-arch builds and assembles an OCI image index (manifest list)

Test plan

• ContainerPlatformTest — single/multi-arch parsing, round-trip, equality, matching
• ContainerControllerTest — multi-platform validation and request handling
• ChildEntriesTest — encoding, round-trip, Jackson serialization, template binding
• BuildRequestTest — Jackson serialization with child entries
• ContainerScanServiceImplTest — multi-platform scan fan-out

🤖 Generated with Claude Code

[pditommaso]

@munishchouhan when you have some capacity, it would be useful to stress this a bit to make sure there no regression.

containerPlatform allow linux/amd64,linux/arm64 in the build request. For all others it should remain the same

[pditommaso]

Multi-arch augmentation and Fusion layer filtering

Problem

When containerPlatform is multi-arch (e.g. linux/amd64,linux/arm64), the container resolution process in ContainerAugmenter only augmented one platform manifest from the image index. This meant the other architecture was left unaugmented, resulting in incorrect multi-platform images.

Additionally, fusion layers were not filtered by architecture — both fusion-amd64.tar.gz and fusion-arm64.tar.gz would be injected into every platform manifest, regardless of its target architecture.

Solution

Multi-arch augmentation (ContainerAugmenter)

• Added resolveImageIndex() — a unified handler that iterates over all matching platform entries in a manifest index (both single-arch and multi-arch)
• Added augmentManifest() — shared logic to fetch config, filter layers by architecture, and update the config + manifest for a single platform
• Added matchesPlatformEntry() to check if an index entry matches any of the target platforms
• updateImageIndex() now accepts a Map<String, AugmentedManifest> to batch-update all augmented entries in one pass
• Introduced AugmentedManifest inner class (digest + size) replacing the previous Tuple2<String, Integer>

Fusion layer filtering (MultiPlatformBuildService)

• Added filterLayersForPlatform() — filters fusion layers by matching the architecture suffix in the layer URL (e.g. fusion-amd64.tar.gz → keeps only for amd64)
• Non-fusion layers (no arch suffix) pass through unfiltered
• Used at build time in createPlatformRequest() and at augmentation time in augmentManifest()

Platform matching (ContainerPlatform)

• Moved matches(), sameOs(), sameArch(), sameVariant() into the Platform inner class where they belong
• Guarded getOs()/getArch()/getVariant() on ContainerPlatform to throw IllegalStateException when called on a multi-arch instance (marked @Deprecated)
• Fixed PullMetricsRequestsFilter to handle multi-arch platforms safely

Other improvements

• Moved skip-build-cache from wave.debug to BuildConfig (wave.build.skip-cache, default false)
• Fixed body.bytes double computation in ManifestAssembler
• Fixed double JSON parsing in parseManifest overloads

Result

Each platform in a multi-arch image index now gets augmented with the correct arch-specific fusion layers: amd64 manifests receive fusion-amd64.tar.gz, arm64 manifests receive fusion-arm64.tar.gz.