Structured image builds and images.json

[KA-ROM]

A container that pins a source repo used to describe its build as a shell line. That string is only useful to a local docker or podman run: nothing else can tell the repo from the Dockerfile from the secrets, so anything that builds decker's images elsewhere ends up keeping a second copy of the pins, and the two drift.

ImageBuildSpec now carries the build in fields — repo, ref, name, variant, version, dockerfile or assetDockerfile, assets, target, buildArgs, secrets — and the build command is derived from them. cmd stays as an escape hatch for a build no combination of fields expresses.

decker build writes every spec to manifests/<recipe>/images.json, keyed by the tag the manifests actually reference. A builder in CI or in a cluster reads that one file and builds exactly what the run will pull. With DECKER_IMAGE_MODE=pull decker builds nothing itself and only references the tags.

Build inputs that are not in the source repo — a Dockerfile that patches it, the patches it applies — can sit with the recipe that needs them. assetsDir points a spec at the directory that owns them, so a recipe living in its own repo ships its own build inputs instead of adding them here. Those bytes hash into the image tag, so a patched image can never collide with a pristine one, and they are copied next to images.json for whoever does the building.

The rest is in support of running a mainnet-shaped L1:

• MAINNET_SYSTEM_CONTRACTS predeploys the EIP-4788, 2935, 7002 and 7251 contracts the EL system-calls every block. With no code at those addresses the block's state diff takes a shape mainnet never produces.
• L1 artifacts take withdrawals: "none" for BLS credentials, so a devnet can run without per-block withdrawal sweeps.
• scripts/trie-padding.ts creates N fresh accounts before load. decker's genesis is a dozen accounts, and a builder whose root hasher is only ever exercised on mainnet-deep tries can compute wrong roots against a trie that shallow.
• lighthouse takes config.feeRecipient, because a builder that proves the proposer payment against state needs a recipient that exists in genesis.

Tested with deno lint, deno check over all tracked TypeScript, 14 unit tests and the e2e suite against the compiled binary. New coverage: the derived build command, the images.json payload, assets owned by an out-of-tree recipe, and an e2e test asserting that every tag in images.json is referenced by the rendered manifests.

[canercidam]

Could we move this to notes/images.md?