feat: add pipeline_types, pipeline_flowctl, pipeline_secrets modules

[elasticdotventures]

Summary

Extracts pipeline_types.rs, pipeline_flowctl.rs, and pipeline_secrets.rs from b00t-cli (elasticdotventures/_b00t_) into this crate, so a lightweight pipeline-engine consumer can depend on ufo-types for StageSpec/CapsuleProfile/flow-control/secret-injection types instead of the full 34-submodule _b00t_ monorepo. Implements elasticdotventures/_b00t_#1251.

• pipeline_types: StageSpec, CapsuleProfile, StagePort, PipelineError, ErrorRoute, StageEntry, PipelineDag (stage wiring, topological ordering, cycle detection), ResourceRequirements/HostResources.
• pipeline_flowctl: FlowStrategy/FlowControl/FlowGate (back-pressure between stages), StageFlowConfig.
• pipeline_secrets: SecretRef/SecretStore/SecureStageEnv (secret resolution/injection into stage environments — file, env var, keyring, interactive prompt, Azure Key Vault sources).

Key design decision: Satisfies port

HostResources's Satisfies<ResourceRequirements> impl is ported, not copied verbatim — the original targets b00t_c0re_lib::satisfies::Satisfies (fn satisfies(...) -> anyhow::Result<EvidenceReport>, a different crate's trait); this PR rewrites it against ufo-types' own crate::satisfies::Satisfies (fn satisfies(...) -> SatisfiesResult, infallible), since the whole point of landing this code here is to use this crate's own constraint-satisfaction shape. The passing case has no free-text detail field in the new shape (only Violated carries a reason), so that diagnostic text is intentionally dropped rather than misused as a fabricated evidence-graph NodeId — documented inline at the impl site.

Two correctness improvements over the source (not just a copy)

• The keyring feature is a real, working optional dependency here — b00t-cli's own same-named feature is a no-op stub with no crate behind it, so that code path has never actually compiled anywhere.
• Fixed a latent bug in SecretSource::Keyring's match arm: the original discards service/account via service: _, account: _, yet its #[cfg(feature = "keyring")] branch references them by name — this would never have compiled once the feature became real. Verified via cargo build --features keyring.

Review process

Built via subagent-driven-development (2 plan tasks + a final whole-branch review, all independently verified — not self-reported). The final review empirically tested the one open risk from the per-task review (whether rpassword/shellexpand as unconditional dependencies break a hypothetical wasm32 target): cargo check --target wasm32-unknown-unknown passes at the pinned versions, so that risk is closed with evidence, not just a judgment call.

A small set of inherited-from-b00t-cli robustness gaps (a panic on PipelineDag::execution_order() given a deserialized dangling edge, PipelineDag::build failing on default-constructed/name-only stages, an unnecessary buffer allocation in FlowControl::record_emit, a weak redaction test, and a few smaller items) were correctly out of scope for a verbatim extraction but now matter since this crate is the published, external-facing home for this code — tracked as a follow-up: #18.

Test plan

• cargo test --all-features — 212 passed, 0 failed
• cargo test (no features) and cargo test --features keyring — both pass
• cargo fmt --all -- --check clean
• cargo clippy --all-targets --all-features -- -D warnings clean
• cargo package --allow-dirty succeeds
• cargo check --target wasm32-unknown-unknown succeeds (verifies the two new unconditional dependencies, rpassword/shellexpand, don't break a wasm32 build)

🤖 Generated with Claude Code

[elasticdotventures]

Independent review (last-line-of-defence pass)

State: CONFLICTING — needs a rebase before this can merge. Conflict check against current main: exactly 2 conflicting files, both routine additive-list conflicts:

• CHANGELOG.md — version-history list, both sides appended entries (v0.14.0 landed on main after this branch cut).
• src/lib.rs — crate-root module documentation list; main added the ontology + sysml_model/view doc blocks (from #23, now released as v0.14.0), this branch adds its three pipeline module doc entries. Textually adjacent insertions → conflict, but semantically independent — resolution is "keep both."

Both resolve mechanically (union, no semantic judgment needed). No conflicts in the new module files themselves or Cargo.toml beyond the changelog entry.

On the content (CI on the branch is green — both checks pass): +3763/-0, 7 files, adds pipeline_types/pipeline_flowctl/pipeline_secrets modules. Consistent with this crate's conventions (pure data, non_exhaustive closed vocabularies, domain-generic). No red flags from the diff shape.

Verdict: not mergeable today — rebase on main (2 mechanical conflicts), then it's a sound candidate. Note for the rebase: PR #25 (NaN fix in coherence.rs) may also land on main first; it doesn't touch these files, so no additional conflict.