ci(p0): stabilize workflow topology and freeze CI-sprawl baseline

[masarray]

Closes #426

Purpose

CI-P0 is a stabilization milestone before any workflow consolidation. It does not remove checks, change IEC 61850 runtime behavior, alter physical acceptance semantics, or change release/promotion authority.

Adds

• deterministic read-only workflow inventory;
• synthetic tests for duplicate job IDs and duplicate step-name corruption within one job;
• machine-readable CI-sprawl budget;
• lightweight workflow-integrity guard that runs only when workflow/CI-P0 files change;
• ownership/baseline documentation for later CI-P1/P2 consolidation.

Frozen pre-P0 observations

• 28 tracked workflows;
• 12 setup-dotnet uses;
• 15 dotnet restore invocations;
• 15 dotnet build invocations;
• 17 dotnet test invocations;
• 31 checkout uses;
• 33 upload-artifact uses;
• 0 reusable workflow_call entry points.

The new P0 guard itself adds one workflow and one checkout but no .NET setup/restore/build/test and no uploaded artifact. The reviewed budget freezes that post-P0 topology so CI duplication cannot silently grow.

Non-goals

• no workflow retirement;
• no reusable workflow migration yet;
• no engine/runtime source change;
• no physical evidence rewrite;
• no release/promotion policy change.

P1 should use this baseline as the before-state and reduce the expensive counts rather than adding another parallel pipeline.

[masarray]

CI-P0 self-validation on head 6e0aadcc81dada62141c26b53e3cb7f50740358f:

• offline corruption/budget fixtures: 5/5 PASS;
• workflow structure/budget inventory: PASS;
• observed topology after adding P0 guard: workflows=29, restore/build/test=15/15/17, setup-dotnet=12, checkout=32;
• the P0 guard itself adds no .NET setup/restore/build/test and uploads no artifact;
• mainline/production/merge/golden/repeat-run legacy guards checked so far remain green.

Representative CI-storm evidence: this infrastructure-only PR triggered 9 Actions workflows. Several independently restore/build/test or package the same unchanged application path. This observation is intentionally recorded as a CI-P1 optimization target, not "fixed" by weakening P0 semantics.

PR diff is additive only: one lightweight workflow, two read-only Python scripts, one budget JSON and one audit document. No application, engine, release, or field-authority source is modified.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-06T21:22:37.854627Z	6e0aadc	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e0aadcc81

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Parse job indentation instead of assuming two spaces

When a valid workflow uses four-space job indentation, this regex records no job IDs; because an empty jobIds collection is not itself an error, duplicate job IDs and duplicate step names in that workflow pass the integrity guard as healthy. Derive nesting from YAML indentation or explicitly reject unsupported layouts, and cover the alternate indentation with a regression fixture.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Budget the computed pull-request workflow count

When pull_request is added to an existing push-only workflow, pullRequestWorkflows increases but none of these limits changes, so the budget remains healthy even if another full build/test workflow now runs on every PR. Since the inventory already computes this metric, freezing its baseline here is necessary for the guard to detect this CI-sprawl scenario.

Useful? React with 👍 / 👎.