CI import: migrate GitHub Actions and Azure Pipelines into idiomatic Fallout C#

[ChrisonSimtian]

@

Problem

Adopting Fallout on a project that already has CI means hand-rewriting every
workflow — there's no path in. And moving a pipeline between hosts (GitHub
Actions ⇄ Azure Pipelines) is a full manual rewrite each direction.

Outcome

A fallout migrate <host> command reads existing CI YAML and emits idiomatic
Fallout C#. The forward generators already exist; this adds the reverse. Once a
project's logic lives in C#, retargeting another host is a regenerated shim
(./build.ps1 <Target>), not a second migration — Fallout becomes the
translation layer between hosts.

Two buckets on import:

• Lift — recognized commands (dotnet build/test/restore/pack, …) become
  tool-wrapper targets.
• Stub — anything unconvertible (marketplace actions, host-native deploy)
  becomes a compiling target that throws NotImplementedException, carrying
  the original step and source ref inline for a human to finish.

Acceptance criteria

• fallout migrate github reads .github/workflows/*.yml → emits/updates Build.cs + [GitHubActions]
• fallout migrate azure does the same for azure-pipelines.yml + [AzurePipelines]
• Recognized .NET commands emit idiomatic tool-wrapper targets (e.g. dotnet test --no-build → DotNetTest(s => s.EnableNoBuild()))
• Unconvertible steps emit a compiling stub: original step inline + path:line ref + NotImplementedException
• --dry-run reports lift/stub counts per host, writes nothing
• Round-trip: regenerating CI from emitted C# diffs cleanly against the original for lifted steps
• Nothing is silently dropped

Notes

• Architecture: reuse ConfigurationEntity as a shared IR; readers (IConfigurationReader) symmetric with the existing IConfigurationGenerator writers. Forward side + tool catalog already exist (~half the work).
• Recognizer can ship empty and grow — without it, lifted steps fall back to shell Executes; the rest still stubs. So MVP = readers + C# emitter + stub emitter + CLI.
• GitLab and other hosts out of scope for first cut.
  @

[ChrisonSimtian]

@
Design doc drafted: docs/design/ci-import.md (branch docs/ci-import-design).

Covers the import/export asymmetry (why import can be best-effort), reuse of ConfigurationEntity as a shared IR with IConfigurationReader symmetric to the existing generators, the lift/stub model, build order (MVP = readers + emitters + CLI; the command recognizer is the quality dial, not a blocker), and round-trip validation against the existing forward generators.
@