Add product environment expected config status

[cbusillo]

Objective

Expose an environment config-status projection that reports expected runtime keys and managed secret bindings as configured, missing, disabled, unvalidated, stale, or unsupported without revealing values.

Finish Line

Product environments report expected config status without exposing values

Current Status

State: PR #428 merged and deployed. Launchplane now supports product-profile/onboarding expected config requirements and the redacted product environment config-status read endpoint GET /v1/products/{product}/environments/{environment}/config-status.
Next action: Use the endpoint from the operator UI/agent context work when #153/#379 resumes; direct local terminal-agent access remains tracked in #426.
Blocked by: No blocker for this slice. #426 still blocks browserless local terminal reads.
Last verified: 2026-05-07 after PR #428 merge: local focused unittest suite, changed-file ruff, targeted mypy, PR CI/Security/CodeQL, post-merge CI/Security/CodeQL, Deploy Launchplane run 25527196368, and live health trace launchplane_req_878e99c0ed004548bb000ee83fd08479.

Scope

• Represent expected runtime keys and managed secret binding keys for product environments without storing plaintext values in GitHub or product repos.
• Add or extend a read model that reports key presence/status by product and environment.
• Include enough metadata to answer diagnostic questions such as whether preview/testing/prod has RESEND_API_KEY and related email config configured.
• Keep the response product-neutral; product-specific expected keys should come from records, profile/config manifests, driver metadata, or another explicit Launchplane-owned source.
• Preserve existing redaction rules: no plaintext secret values, ciphertext, full provider env dumps, or token prefixes.

Acceptance Criteria

• A caller can request config status for a product environment and see expected runtime keys and managed secret bindings marked as configured, missing, disabled, unvalidated, stale, or unsupported.
• Missing expected keys are explicit in the response instead of requiring clients to infer absence from current binding lists.
• Managed secret entries include binding key/status/source metadata only, never plaintext or ciphertext.
• Runtime setting entries include key names/status/source metadata only unless an existing redacted value policy explicitly allows non-secret display.
• Tests cover configured, missing, disabled, stale/unvalidated if available, and unsupported cases.
• Docs describe how this differs from full runtime environment resolution and secret status reads.

Relationships

• Subissue of Make Launchplane a read-only agent context provider #379.
• Related to Add secret-backed action contract without plaintext reveal #387 secret-backed action and binding status work.
• Related to Finish product/environment API before UI rebuild #152 product/environment API and Rebuild operator UI around product environments #153 operator UI product environment views.
• Related to Add read-only terminal-agent auth for Launchplane context #426 for terminal-agent access to the redacted status surface.
• related: Add secret-backed action contract without plaintext reveal #387 - Add secret-backed action contract without plaintext reveal #387
• related: Rebuild operator UI around product environments #153 - Rebuild operator UI around product environments #153
• related: Add read-only terminal-agent auth for Launchplane context #426 - Add read-only terminal-agent auth for Launchplane context #426

Validation

• Unit tests for expected-key status projection over runtime settings and managed secret bindings.
• Service tests for authz and redaction on the config-status endpoint or read-model extension.
• A staged/live smoke can answer SellYourOutboard email readiness by environment without exposing Resend or email secret values.

Decisions

• Do not promote to production solely to discover whether a secret binding exists.
• Do not make agents read plaintext secrets to diagnose environment readiness.
• Prefer Launchplane-owned expected config metadata over product-repo hard-coded diagnostics.

Open Questions

• Should expected keys live in product onboarding/profile records, product-config manifests, driver descriptor requirements, runtime key-safety policy, or a new environment requirement record?
• Should this be a new route such as /v1/products/{product}/environments/{environment}/config-status or an extension of existing environment detail?
• Should preview config requirements differ explicitly from testing/prod requirements, and how should unsupported preview-only secrets be represented?