Scope ${GITHUB_*} → ${{github.*}} rewrite to non-run: contexts

[ydesgagn]

Summary

The workflow writer was running a blanket regex substitution across the entire rendered YAML, rewriting every ${GITHUB_*} into the GitHub expression form ${{github.*}}. That rewrite is correct for env:, if:, with:, concurrency:, run-name:, etc. (where ${GITHUB_*} is not shell-expanded and the canonical expression form is required), but wrong inside shell run: blocks: there ${GITHUB_*} is the env-var syntax the runner actually exports, while ${{github.*}} is opaque to shellcheck and trips SC2193.

Instead of removing the translation outright (the first attempt — which broke env: values that have no other way to interpolate github.* context), this scopes it: we walk the parsed YAML tree before serialization and skip values whose enclosing key is run. Every other context still gets the canonical ${{github.*}} form.

Key changes:

• Replace the blanket-string gsub! in Workflow#write with a recursive rewrite_github_refs helper that walks the hash/array structure and applies the regex only to non-run: string values
• Extract the regex to a private_constant (GITHUB_ENV_VAR_REGEX)
• Update the existing ${GITHUB_*} → ${{github.*}} spec (env: context, still translated) and add a new spec verifying ${GITHUB_*} inside step run: bodies is preserved verbatim

Types of changes

• Bugfix (fixes an issue)
• New feature (adds functionality)
• Refactoring (improves code without changing functionality)
• Breaking change (incompatible changes)
• Build or security update (updates dependencies, libraries, or security patches)
• Code style or documentation update (formatting, renaming, or documentation changes)
• Other (please describe):

Checklist

• Unit tests added to validate my fix/feature
• I have manually tested my change
• I did not add automation test. Why ?:
• Database changes requiring migration with downtime or reprocessing of existing data
• The SOUP file lists the risk Level, requirements and verification reasoning associated with each library
• `readme.md` includes sections on introduction, installation, usage, and contributing
• `docs/architecture.md` includes sections on the architecture diagram, software units, software of unknown provenance, critical algorithms and risk controls related to PII and security
• Impact on PII, privacy regulations (CCPA/GDPR/PIPEDA), CIS benchmarks or security (availability/confidentiality/integrity); management must be notified