Restore application configuration without leaking credentials

Repair catalog.yaml. Preserve the store/catalog Deployment (apps/v1), two replicas, catalog container, registry.example/catalog:8 image, catalog-runtime account, and matching Deployment/template labels. Supply APP_MODE=production and API_URL=https://orders.store.svc from ConfigMap data, and API_TOKEN=demo-credential-7A from an Opaque Secret. The credential is an inert practice value. Objects and references are namespace-local; keep their namespace explicit. The supplied application first reads each direct environment variable; if absent, it reads the file named by the corresponding APP_MODE_FILE, API_URL_FILE or API_TOKEN_FILE variable. It starts successfully only when all three resulting values match these facts and every required environment, projection and mount dependency is available. Optional missing references can be skipped by Kubernetes but cannot supply an absent required application value. Public inputs must originate in ConfigMaps and private inputs in Secrets, even if a copied literal could technically start the process. Keep the credential and its base64 representation out of ConfigMaps, workload literals and metadata. Resolve inputs through key references/envFrom, mapped ConfigMap/Secret volumes, or a mixture. Explicit env overrides envFrom; later envFrom imports override earlier imports. Secret stringData overrides same-key decoded data. The supported manifest subset is Deployment identity/selectors, env/envFrom, ConfigMap data, Opaque Secret data/stringData, and non-overlapping config/secret mounts with optional items/subPath. Other Pod features and shell expansion are outside the model. Inspect unresolved-reference evidence and repair without Reset.