Declare CD environments in the build definition instead of clicking them into GitHub

[ChrisonSimtian]

Problem

Fallout generates workflows from [GitHubActions], but the environments those workflows reference — and the secrets they import — have to be created by hand in the GitHub UI. A generated workflow carrying environment: ghcr is valid YAML that fails opaquely at runtime if the environment does not exist or its secrets are unset: the job starts, runs for ~40s, and dies inside a docker login with a message that names neither the environment nor the missing secret.

Protection rules (required reviewers, wait timer, deployment branch policy) are click-ops for the same reason — not diffable, not reviewable, not roll-back-able, and invisible to anyone reading the build definition.

Outcome

The environments a build's workflows depend on are declared in the build definition and reconciled against GitHub, and a missing environment or an unset required secret is reported by name, before CI runs.

The build definition already holds both halves — EnvironmentName says which environment, ImportSecrets says which secrets it must carry — so this needs no new source of truth, only somewhere to act on what is already declared.

Acceptance criteria

• Environments referenced by EnvironmentName can be reconciled against the repo without hand-creating them in the UI
• Protection rules (required reviewers, wait timer, deployment branch policy) are expressible in the build definition
• Reconciliation is idempotent — re-running against an up-to-date repo is a no-op, not a recreate
• Secrets named by ImportSecrets are verified to exist and reported by name when absent
• Secret values are never created, read, or logged by Fallout
• Repos without protection-rule entitlement (private repos on Free) degrade with a warning rather than failing

Notes

• Environments are API state, not files — this is reconciliation, not code generation, so it wants a host command plus a token with repo admin, rather than an extension of --generate-configuration.
• Secret values stay irreducibly manual. The win is not automating them; it is failing fast with the exact missing names instead of an opaque docker login error deep in a CI run.
• Motivated by real setup friction in Chrison-dev/Krautwatch#24 — one environment per container registry, so a token for one registry is never in scope for a push to another.

Could you help with a pull-request?

Yes