fix(parser): prevent webhook body with 'key' field from being silently dropped (fixes #5333)

[asheesh-devops]

Summary

Fixes a bug where a workflow step POSTing a JSON body with a field named "key" would silently discard all other fields, sending only the value of the "key" field as a string instead of the full JSON object.

Root Cause

In parse_provider_parameters(), when a parameter value is a dict, the code unconditionally attempts to coerce it into a StepProviderParameter(**dict). Since StepProviderParameter only requires a key field:

class StepProviderParameter(BaseModel):
    key: str
    safe: bool = False
    default: str | int | bool = None

Any user dict containing a "key" field is silently converted — all other fields are discarded:

# User workflow:
body:
  key: ALERT
  host: "{{alert.service}}"
  time: "{{alert.lastReceived}}"

# What gets sent: "ALERT" (just the key value, everything else lost!)

The Fix

Only attempt StepProviderParameter coercion when the dict exclusively contains its known fields (key, safe, default):

# Before (broken):
try:
    parsed = StepProviderParameter(**param_value)  # Any dict with "key" gets coerced!
except Exception:
    parsed = param_value

# After (fixed):
known_fields = {"key", "safe", "default"}
if param_value.keys() <= known_fields and "key" in param_value:
    # Only coerce dicts that look like a StepProviderParameter
    parsed = StepProviderParameter(**param_value)
else:
    # User dict with extra fields — preserve as-is
    parsed = param_value

Changes

• keep/parser/parser.py — add field validation before StepProviderParameter coercion in parse_provider_parameters()

Testing

• A dict like {"key": "ALERT", "host": "...", "time": "..."} now passes through as-is (has extra fields beyond key/safe/default)
• A dict like {"key": "alert.name"} still correctly becomes a StepProviderParameter (only known fields)
• A dict like {"key": "alert.name", "safe": true, "default": "N/A"} still correctly becomes a StepProviderParameter
• The <= (subset) check ensures forward compatibility if StepProviderParameter gains new optional fields

Fixes #5333