wfectl logs <ci-name> returned nothing because each sub-workflow's
step logged under its own UUID. The LogStore is keyed by workflow_id,
so querying the parent ci ID found zero entries. Now stream_logs uses
root_workflow_id (the top-level ancestor) so all sub-workflow output
aggregates under the ci run the user actually started.
Sub-workflow steps were not getting a PVC because the K8s executor
checked context.definition.shared_volume which is the child definition
(e.g. lint) — not the root (ci) that declares shared_volume. Only
root definitions carry the config; sub-workflow definitions don't.
Fix: WorkflowHost::start_workflow_with_name injects the config as
_wfe_shared_volume in instance.data. SubWorkflowStep propagates the
parent's data to children, so the config reaches every descendant.
The K8s executor reads it from workflow.data when
definition.shared_volume is None.
Adds a regression test that mirrors the real topology: a child
workflow instance with root_workflow_id set, no shared_volume on its
definition, and _wfe_shared_volume in data — must still get the PVC.
Kubernetes step jobs with a `run:` block were invoked via
`/bin/sh -c <script>`. On debian-family base images that resolves to
dash, which rejects `set -o pipefail` ("Illegal option") and other
bashisms (arrays, process substitution, `{1..10}`). The first line of
nearly every real CI script relies on `set -euo pipefail`, so the
steps were failing with exit code 2 before running a single command.
Switch to `/bin/bash -c` so `run:` scripts can rely on the bash
feature set. Containers that lack bash should use the explicit
`command:` form instead.
Pure formatting pass from `cargo fmt --all`. No logic changes. Separating
this out so the 1.9 release feature commits that follow show only their
intentional edits.
