Finalize Universal Integration Keys for Stable Release

[mastercactapus]

What problem would you like to solve? Please describe:

We need to finalize and polish the Universal Integration Keys (UIK) feature so it can be moved out of the experimental state. The current pain points include:

• Missing guidance on how to use a UIK.
• No links or info on writing Expr expressions.
• No straightforward way to test conditions and actions.
• Adding and editing actions is confusing.
• No visibility into whether recent requests worked, failed, or even occurred.
• Handling of invalid data returns a 500 instead of a 400 error.

Describe the solution you'd like:

Must-have enhancements:

• Display a copyable POST endpoint URL on the Edit page, and clarify that requests should use Authorization: Bearer <token> (PR uik: add some clarity to using universal keys  #4189).
• Support multi-line edit fields with syntax highlighting.
• Add query parameters to the Expr evaluation environment.
• Include an info icon indicating that the expressions use the Expr language, with a link to relevant documentation.
• Provide a way to test an individual expression using a given JSON payload and query string.
• Improve the action editing flow to make it more intuitive.

Additional improvements:

• Allow testing the entire key with a given JSON payload and query string, and show which rules evaluated and how.
• Log recent requests (both successes and failures) to aid in debugging.
• Support saving test payloads for quick reuse.

Additional context:

• The top-level card should include instructions on how to make a request, preferably in a sidebar or prominent location.
• In edit dialogs, add a << Debug button that expands a panel to the left. This panel should allow selecting/editing a test request. All Expr editors should use the test request data as input and display evaluated output in real-time (e.g., in a bottom overlay) when fields are focused.

Action editing/adding flow:

• Show only an "Add Action" button initially. When clicked, reveal a screen for choosing the destination type and disable other controls until a choice is made.
• In this "Add Action" view, provide two buttons: "Save this Action" and "Delete this Action".
• On the main action list (chips), replace the delete icon with an edit icon. Clicking edit enters the same flow as add, and from there the action can be deleted if needed (no direct delete from the chip list).

[mastercactapus]

Possible idea for the "info icon" placement

And from there link to https://expr-lang.org/docs/language-definition or a tooltip with the tagline from the Expr homepage (including syntax link)

Expr is a Go-centric expression language designed to deliver dynamic configurations with unparalleled accuracy, safety, and speed. Expr combines simple syntax with powerful features for ease of use:

If that's not feasible in the UI code, we could alternatively do something in the Top-Right corner like Tooltip: "This dialog uses Expr syntax for dynamic field values. Learn more" though by the actual fields would be best.

[mastercactapus]

UIK actions changes

• change chip to non-clickable
• change icon to Edit icon (tooltip, if possible, to "Edit or Delete")
• No destination form when not adding/editing
• Display "+ Add an action..." as a chip after the list of actions, when not adding/editing
• Disable back/next/submit buttons while adding/editing
• When ADDING: show "Cancel" and "Save" buttons
• When EDITING: show "Cancel", "Delete", and "Save" buttons
• It's okay for now that default actions dialog will have 2 cancel buttons at a time (the top-level one will be disabled in this case)

Longer term (or instead) we'll render rules independently, similar to escalation policy steps and not have sub-flows in the dialog.