Evaluate environment-scoped config (project environments) for per-env values

Idea

Today gocdnext secrets are project-scoped: secrets(project_id, name) — one value per name. There's no GoCD-style environment that holds the same variable/secret name with a different value per environment (stage/prod). The environments table exists but is deployment tracking only (no variables/secrets).

Teams coming from GoCD expect: define KEYCLOAK_SECRET once, give it a stage value and a prod value, and have the right one resolve per environment.

Current model (the workaround)

• Distinct secret names per env: FOO_STAGE / FOO_PROD, each referenced by its own pipeline file (e.g. deploy-stage.yaml vs deploy-prod.yaml).
• With an external secret backend (Vault/GCP/AWS), the per-env value already lives at a per-env path — gocdnext just maps names → backend refs.
• For a fixed config placeholder, the plugin maps it per pipeline (e.g. the gravitee plugin's config_secrets: "PLACEHOLDER=${{ FOO_STAGE }}").

This works and is explicit, but carries _STAGE/_PROD suffixes and some duplication across the per-env pipeline files.

Why it may not be worth it

• The external backend (Vault, etc.) is already the per-env source of truth (different paths) — project environments would duplicate that resolution.
• The per-env distinction already lives in separate pipeline files (different gates/triggers). Env-scoping would only drop the name suffix, a marginal gain.
• Explicit references (${{ FOO_STAGE }}) are easier to audit than hidden env-scoped resolution — desirable for a CI/CD secret surface.
• It's a sizeable feature: env-scoped storage + resolution + UI + the binding semantics (which env a given run resolves against).

When it would clearly pay off

If gocdnext gains environment-parameterized pipelines (one pipeline definition executed per environment, instead of separate per-env files). Then env-scoped variables/secrets become the natural fit.

Ask

Decide whether to (a) keep the explicit per-name model, (b) add lightweight shared/per-env variable blocks, or (c) build full environment-scoped config — ideally alongside any move toward env-parameterized pipelines.

Filed from a discussion while wiring per-environment OAuth/Keycloak secrets into the gravitee plugin (the config_secrets mapping covers the immediate need).

Start by tracing the current secrets(project_id, name) model, the environments table, and the gravitee plugin's config_secrets mapping. Compare the explicit deploy-stage.yaml and deploy-prod.yaml approach with the three requested options. Done means documenting a project decision and its scope; the issue does not identify implementation files or tests.