DAP: add JobExecutionView model + renderer

[rentziass]

This is part 1 of 2 of the work to serve the job "source" during debugging.

In this PR is all the code to build that representation: this is intended to be a 1:1 representation of how the runner sees the job it's executing rendered as YAML, it's not the workflow file the job comes from; this allows us to consider pre and post actions steps as "lines" we can pause/add breakpoints (coming next) and show things exactly as the runner interprets them. We use YamlDotNet to render scalar values but we "hand-write" the source skeleton because we need to keep track of each step's line to be able to refer to it later (and to write comments but that's secondary at the moment).

Example YAML served as source

# Job: build
# Runner execution plan — read-only.

setup:
  - step: Setup job

main:
  - step: Run actions/checkout@v6
    uses: actions/checkout@v6
    if: success()
  - step: Cache Primes
    id: cache-primes
    uses: actions/cache@v5
    if: success()
    with:
      path: prime-numbers
      key: ${{ runner.os }}-primes
  - step: Check prerequisites
    run: |
      echo banana
      echo "Checking system requirements..."
      echo "Node version: $(node --version 2>/dev/null || echo 'not installed')"
      echo "Python version: $(python3 --version 2>/dev/null || echo 'not installed')"
    if: success()
  - step: Install dependencies
    run: |
      cat > package.json << 'EOF'
      {
        "name": "demo",
        "scripts": {
          "build": "node build.js",
          "test": "node test.js"
        }
      }
      EOF
      cat > build.js << 'EOF'
      const fs = require('fs');
      const config = require('./config.json');
      fs.writeFileSync('dist/output.js', `// Built for ${config.env}`);
      EOF
    if: success()
  - step: Build
    run: |
      mkdir -p dist
      npm run build
    if: success()
  - step: Verify build
    run: |
      test -f dist/output.js && echo "Build successful!"
    if: success()

post:
  - step: Post Cache Primes
    action: actions/cache@v5
  - step: Post Run actions/checkout@v6
    action: actions/checkout@v6

cleanup:
  - step: Complete job

[Copilot]

Pull request overview

This PR introduces the core model + rendering pipeline for a DAP “job execution view”: translating runner steps into a pure-data representation and rendering that representation as stable, line-addressable YAML (intended to mirror how the runner will execute the job, not the original workflow file).

Changes:

• Added JobExecutionViewEntry/JobExecutionPhase plus a deterministic YAML renderer that tracks each entry’s - step: line.
• Added a stateful JobExecutionView container to append entries during execution and resolve IStep identity → YAML line in O(1).
• Added StepEntryTranslator and TemplateTokenYamlAdapter to preserve author-facing expressions when emitting YAML fragments, plus L0 coverage.

Show a summary per file

File	Description
src/Runner.Worker/Dap/TemplateTokenYamlAdapter.cs	Adapter to serialize TemplateToken back to YAML while preserving expression display forms.
src/Runner.Worker/Dap/StepEntryTranslator.cs	Translates IStep/IActionRunner into JobExecutionViewEntry data for rendering.
src/Runner.Worker/Dap/JobExecutionViewRenderer.cs	Pure renderer producing execution-view YAML and per-entry start line mapping.
src/Runner.Worker/Dap/JobExecutionView.cs	Stateful append-only view with cached YAML and step→line lookups, plus placeholder claiming/skipping.
src/Test/L0/Worker/TemplateTokenYamlAdapterL0.cs	Unit tests for YAML serialization of TemplateToken values and expressions.
src/Test/L0/Worker/StepEntryTranslatorL0.cs	Unit tests for translating runner steps into view entries.
src/Test/L0/Worker/JobExecutionViewRendererL0.cs	Unit tests for rendering format, field ordering, quoting, and line number stability.
src/Test/L0/Worker/JobExecutionViewL0.cs	Unit tests for append/claim/skip behavior and concurrency safety in the stateful view.

Copilot's findings

Comments suppressed due to low confidence (4)

src/Test/L0/Worker/JobExecutionViewRendererL0.cs:475

• iStep is computed but never used, which triggers CS0219 and fails the build when warnings are treated as errors. Remove the unused local (or actually use it as part of the ordering assertions).

            int iStep = y.IndexOf("    - step: ", StringComparison.Ordinal) >= 0
                ? y.IndexOf("- step:", StringComparison.Ordinal) : y.IndexOf("- step:", StringComparison.Ordinal);
            int iId = y.IndexOf("    id:", StringComparison.Ordinal);

src/Runner.Worker/Dap/StepEntryTranslator.cs:138

• This lookup uses "working-directory", but ActionStep.Inputs keys for script steps are workingDirectory (see PipelineConstants.ScriptStepInputs.WorkingDirectory and ScriptHandler). As-is, workingDirectory will never populate in the view. Update the key(s) used here accordingly.

                            }
                        }
                        if (TryGetMapValue(inputs, "working-directory", out var wdTok) && wdTok != null)
                        {
                            string wdText = wdTok.ToString();
                            if (!string.IsNullOrEmpty(wdText))
                            {
                                workingDirectory = wdText;
                            }
                        }

src/Test/L0/Worker/StepEntryTranslatorL0.cs:254

• These tests use the run-step input key working-directory, but the runner’s ActionStep.Inputs uses workingDirectory (see PipelineConstants.ScriptStepInputs.WorkingDirectory). Once the translator is fixed to read the real key, update the test to match (and optionally add coverage that both spellings are accepted if you support backward compatibility).

            {
                Reference = new ScriptReference(),
                Inputs = Map(
                    ("script", Str("npm test")),
                    ("shell", Str("bash")),
                    ("working-directory", Str("./api"))),
            };

src/Test/L0/Worker/StepEntryTranslatorL0.cs:283

• The translator’s run-step internal key filtering should match the actual input keys (script, shell, workingDirectory). This test currently uses working-directory, which doesn’t align with PipelineConstants.ScriptStepInputs.WorkingDirectory and could mask bugs in the filter logic. Update the test data/expectations to use the real key (or assert both are filtered if you intend to support both spellings).

            var action = new ActionStep
            {
                Reference = reference,
                Inputs = Map(
                    ("mode", Str("ci")),
                    ("script", Str("leak")),
                    ("shell", Str("leak")),
                    ("working-directory", Str("leak"))),
            };
            var mock = NewActionRunnerMock(ActionRunStage.Main, "Run", reference, action);

• Files reviewed: 8/8 changed files
• Comments generated: 5