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

### 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](https://github.com/Chrison-dev/Krautwatch/issues/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