Retain blueprint as /root/blueprint.toml in built images

[ochosi]

Why

This change follows the established patter of Anaconda which retains a kickstart in /root and a similar pattern in bootc disk images that retains Containerfiles in /root.
Today, users who receive a built image have no easy way to know what blueprint produced it or to rebuild it. The RHSM facts we already embed provide some provenance metadata (API type, blueprint ID), but not the full blueprint itself.

This PR writes the complete blueprint to /root/blueprint.toml in every built image. This serves two purposes:

1. Provenance -- anyone inspecting a running system can see exactly what customizations were requested. This is useful for auditing, debugging, and support.
2. Reproducibility -- a user can extract the blueprint and feed it back into the build tooling to produce a similar image. This is not SLSA3-grade provenance (the blueprint is not signed, and the exact package versions are not pinned in it), but it covers the common case of "I have this image, how do I make another one like it?"

What

• A new BlueprintTOML []byte field on OSCustomizations carries the TOML-encoded blueprint through the manifest pipeline.
• osCustomizations() encodes the blueprint using toml.Marshal() (the Blueprint struct already has toml:"..." tags, and BurntSushi/toml is already a dependency).
• OS.serialize() writes it to /root/blueprint.toml via the existing inline-data copy stage mechanism (same pattern as modularity failsafe files).
• User passwords (Customizations.User[].Password) are redacted before marshaling -- the blueprint is deep-copied and passwords are nilled out so they never appear in the image, whether plaintext or hashed.

Design decision

Since this is a proposal, I opted for a minimal implementation. If we decide we want to go ahead and do this, but the architecture is wrong, I'm happy to rework this PR.

Testing

• Built a test image manually with image-builder-cli and verified /root/blueprint.toml exists with expected content
• Unit test verifying the serialized pipeline contains a copy stage targeting /root/blueprint.toml
• Unit tests for TOML encoding and password redaction in osCustomizations()
• Regenerate manifest checksums (all manifests will change due to the new stage)

[supakeen]

Looking at this purely from a functional standpoint, not the implementation:

This is nice to have though there are some concerns.

One is that we'd need to have this functionality gated behind an ImageOption (BuildOption) so we can turn it off for any images produced in build systems that use customizations (e.g. RHUI, LVMified images for clouds, etc). Initially off by default for the cli as we will want to plumb through/make the option available in koji-image-builder and pungi for those systems while the service can toggle it on.

The other is secrets, any file, first-boot, or many of the other customizations can potentially contain secrets. While those secrets would usually be able to be found by root anyhow it'd need quite some thought.

[ochosi]

That all makes sense! Fwiw I had considered many of those angles already, but mostly wanted to get us to decide if this is something we want to do.

I totally agree with gating this (but maybe "on by default"?) and more things may have to be redacted.

First boot customizations etc are tricky because we cannot know what to redact. Might be easiest to just not retain those at all. Ofc that somewhat diminishes the value of the blueprint retention.

[supakeen]

On by default should be the end goal but we'd need to start with off by default until we have deployed and configured versions of koji-image-builder and pungi that turn it off. After that it can be turned on by default in the library if we want to.

This is to make sure that blueprints don't start showing up in Fedora, CentOS, and RHEL composes and marketplace images where blueprints are also used in the pungi configs.