#3184 fix(keda): show JSON-based scaler config in the resources editor

Summary

Issue: Pylon #5246

KEDA scalers created through the Terraform provider with a JSON-based config only populate config_json on the autoscaling response. The resources settings form only read config_yaml when building its default values, so the scaler configuration editor rendered empty for these scalers, even though the scaler itself was correctly configured and running.

This PR displays, edits and saves these scalers as JSON:

• Display: when config_yaml is absent, the form loads config_json pretty-printed and marks the scaler as JSON-based (configFormat: 'json').
• Editor: the label (Configuration (JSON) / Configuration (YAML)), syntax highlighting and hint follow the scaler's format. If a JSON-based config stops being a valid JSON object, a warning says it will be saved as YAML.
• Save: JSON-based scalers are sent back as config_json, so saving from the Console doesn't switch a Terraform-managed scaler to config_yaml (which would create drift). Content that isn't a valid JSON object falls back to config_yaml. Both the editor warning and the payload use the same parseScalerJsonConfig helper.

Changes:

• service-resources-settings.tsx: getDefaultValues falls back to config_json and sets configFormat.
• keda-scalers-fields.tsx: dynamic label, editor language and hint, plus the invalid-JSON warning.
• autoscaling-payload.ts: configFormat is passed through the form request, parseScalerJsonConfig is exported, and JSON scalers are sent as config_json.
• application-creation-flow.interface.ts: optional configFormat on scalers. New scalers default to YAML, and the service creation flow is unchanged.
• Specs for the config_json fallback and config_yaml precedence, the dynamic label and warning, and the payload format, including invalid JSON and valid JSON that isn't an object.

Screenshots / Recordings

Before	After
Scaler configuration editor empty for a Terraform-created scaler	Editor labeled Configuration (JSON) showing the pretty-printed JSON config

Testing

• Changes tested locally in the relevant Console's pages and Storybooks
• yarn test or yarn test -u (if you need to regenerate snapshots)
• yarn format
• yarn lint

PR Checklist

• I followed naming, styling, and TypeScript rules (see .cursor/rules)
• I performed a self-review (diff inspected, dead code removed)
• I titled the PR using Conventional Commits with a scope when possible (e.g. feat(service): add new Terraform service) - required for semantic-release
• I only kept necessary comments, written in English (watch for useless AI comments)
• I involved a designer to validate UI changes if I am not a designer
• I covered new business logic with tests (unit)
• I confirmed CI is green (Codecov red can be accepted)
• I reviewed and executed locally any AI-assisted code

🤖 Generated with Claude Code