Redact environment variable values in vminitd debug logs

[vyncint]

Fixes #518.

What

vminitd logs the full OCI spec / exec process at debug level in ManagedContainer ("created bundle with spec …", "creating exec process with …"), which dumps every NAME=value environment entry into the boot log. Environment variables routinely carry secrets, so container logs --boot web | grep PASSWORD reproduces the leak exactly as described in #518.

This PR adds redactingEnvironmentValues() to ContainerizationOCI's Spec, Process, Hook, and Hooks — it returns a copy with every env value replaced by <redacted> while keeping the variable names (still useful for debugging which variables were set), leaving NAME-only inherit entries untouched — and uses it at both log sites. With this change the same repro shows MY_SUPER_SECRET_PASSWORD=<redacted>.

The helper lives in ContainerizationOCI (rather than privately in vminitd) so host-side users of the framework who log specs get the same tool; it's a small additive API with doc comments. These two vminitd sites are the only places in the repo that interpolate a whole Spec/Process into a log message (the gRPC handlers only log IDs and ports).

Verification

• New SpecRedactionTests (4 tests) cover: values masked / names kept, NAME-only entries passed through, NAME= and values containing = fully masked, hooks' env masked, non-env fields untouched, originals unmutated, and — mirroring the issue directly — that the rendered string no longer contains the secret values.
• Full ContainerizationOCITests suite passes (53 tests).
• make vminitd cross-compiles cleanly against the pinned Swift 6.3 static Linux SDK with warnings-as-errors, so both edited log sites are type-checked for the Linux target.
• swift format lint --strict clean on all touched files.

Per the AI contribution guidelines: this change was developed with AI assistance (Claude Code); every line has been reviewed, and the reasoning above is the complete justification for each change.

[crosbymichael]

Can you rebase on main to fix the SIGPIPE issue found in the tests?

[vyncint]

Rebased onto main (50f7722). The branch now includes #810, which added Tests/ContainerizationOSTests/IgnoreSIGPIPE.swift and the ignoreSIGPIPEForTests() calls in EpollTests, BidirectionalRelayTests and SocketTests — that is the SIGPIPE the Linux job was hitting. The old run died on closingWriteEndSignalsHangup() with exited with unexpected signal code 13, which lines up.

The rebase was content-free: git patch-id --stable is 6cf10e22 before and after, so the diff is byte-identical, still the same three files. Locally on the rebased tree, swift build --target ContainerizationOCI is clean and the four SpecRedactionTests pass.

Two things worth flagging, both my doing:

• The force-push briefly left the branch level with main, so GitHub auto-closed the PR. I reopened it immediately and the head is now 5424632. Sorry for the timeline noise.
• Because of that, the workflows are sitting at action_required and need an approval to run.

[vyncint]

Hi @crosbymichael,

Following up on the rebase. Both workflows are still at action_required on
5424632 and have not run, so there is no CI result yet to confirm the SIGPIPE
fix.

That approval is the only thing blocking. No rush, just flagging it.