Root cause fix, not a patch

The original bug was that formatIndentedYAMLField marshaled the runs-on value standalone, then prepended a fixed 6-space indent to every line including the first sequence item — misaligning subsequent items. The fix wraps the value in map[string]any{fieldName: value} before marshaling, letting go-yaml's own indentation engine produce consistent indentation across all lines. This addresses the actual cause rather than special-casing the symptom, and the same helper is shared by runs-on, strategy, concurrency, container, services, and environment, so all callers benefit.

Regression coverage

• TestCompileCustomJobRunnerLabels reproduces the exact bug report (#70811) end-to-end through CompileWorkflow and asserts both the raw lock-file bytes and the round-tripped YAML structure.
• TestBuildCustomJobsRunsOnForms gained single label array and object with labels cases that pin exact expected indentation.
• safe_jobs_test.go assertions were corrected to the now-proper indentation (previously encoded the buggy output).
• The actions/aw packages added exhaustive RunsOn round-trip tests (scalars, quoted/expression forms, flow/block arrays, group/labels maps, anchors and aliases) covering parse → emit → reparse stability for every shape, which is excellent /tdd-style boundary coverage for a YAML-AST-sensitive area.

Verification

Ran the full affected test surface locally (pkg/workflow, pkg/workflow/actions, pkg/workflow/aw) plus go build ./... — all pass.

Minor observation (non-blocking)

The sourceNodeColumn extraction in source_merge.go/source_sequence.go is a clean, welcome dedup of previously duplicated column-finding logic — no action needed.

Root cause analysis

The bug (#70811) was that formatIndentedYAMLField marshaled the runs-on value alone (e.g. []any{...}) and then manually prefixed fieldName + ":" plus a fixed 6-space indent per line. Because the YAML encoder did not know the value was nested under a parent key, its own internal sequence-indentation math did not account for that extra nesting level, producing doubled dashes after the first list item. The fix wraps the value in map[string]any{fieldName: value} before marshaling, so goccy/go-yaml computes indentation for the actual nested structure, then re-indents only the continuation lines by a fixed 4 spaces. I reproduced both old and new behavior directly (yaml.MarshalWithOptions with/without wrapping) and confirmed the new approach yields correctly aligned sibling labels.

Verified correctness

• Ran go test ./pkg/workflow/... — all RunsOn/CustomJobRunnerLabels tests pass, including the new 27 round-trip cases across scalars, flow/block arrays, group/labels mappings, expressions, and YAML anchors/aliases.
• Confirmed the error path for unmarshalable values (chan int) still fails correctly after wrapping.
• gofmt -l and go vet ./pkg/workflow/... are clean on the changed files.
• The shared sourceNodeColumn() helper in source_merge.go nicely deduplicates three near-identical column-calculation blocks that previously existed separately in source_merge.go and source_sequence.go — good refactor hygiene alongside the bug fix.

Positive highlights

• ✅ Root cause fixed (serialization context), not just the symptom (manual line-prefixing)
• ✅ Extensive regression coverage at both the actions.Workflow and aw.Document levels, including edit-and-reparse stability checks
• ✅ safe_jobs_test.go expectations updated consistently, since extractCustomJobRunsOn/formatIndentedYAMLField are shared between custom jobs and safe-output jobs
• ✅ Doc comments (doc.go files) updated to describe the preserved runner forms

No actionable issues found in the changed lines; this PR is ready to merge.