feat(safe-exec): harden curl validation and add security posture framework

[pshickeydev]

Summary

• Harden validation of target-derived commands and make execution policy explicit through restricted, baseline, and privileged postures, with high, medium, and low aliases.
• Allow consumers to supply engagement-specific destinations and scope preserved environment variables to selected pipeline segments, without requiring static deployment host lists.

Behavior

Curl validation walks options rather than matching a fixed flag set. Unvetted options are denied, URL operands are limited to HTTP(S), and execution disables automatic curl configuration loading. Execution also separates leading environment assignments from argv and preserves caller-supplied hosts when recovering validated segments.

Postures can be configured file-wide through defaults.posture or per profile:

Posture	Curl destination policy
restricted	Explicit hosts required; redirects denied; pipeline profiles require keep_env_heads
baseline	Public destinations permitted; non-global IP literals and internal hostname forms require explicit allowance; redirects denied
privileged	Backward-compatible defaults; an empty host list permits any destination

curl_allowed_hosts and call-time allowed_hosts are combined. keep_env_heads controls which pipeline segments receive preserved or explicitly supplied environment values.

These are command-validation controls, not a network sandbox: hostname policy does not establish DNS ownership or constrain sockets opened by arbitrary child tools.

Compatibility and rollout

• No contracts change is required: the released configuration model accepts these additional fields. Engine semantics validate posture values.
• Includes the version and changelog update for the next engine release.
• Land and tag this first. Consumer #26 adds engagement authorization, scoped discovery, and structured HTTP execution; its dependency pin and lockfile must be updated after the tag exists.
• Estate #6 adopts restricted validation and must land after the compatible consumer is deployed.

Verification

Previously recorded engine verification: 216 tests passed in tests/test_safe_exec.py, Ruff clean, and release gates clean. Consolidating this PR into one signed commit did not change its tree. The consumer's subsequent regression runs used this engine checkout.

Description prepared with AI assistance.

[chubirka]

@pshickeydev I think I might approach this as a bigger config. Maybe a safe-exec.yaml.example with multiple types of "safe exec" configuration options. Maybe it won't be large at first and then we can make it additive. We could have "postures" of: high, medium, low. High = "fail closed" and Low= "fail open" and then medium is somewhere in between. Similar to k8s Pod Security Standards where there is privileged, baseline and restricted: https://kubernetes.io/docs/concepts/security/pod-security-standards/ I think you have the right idea, but I'd like to see it more broadly applied and portable.