HTTP Action - Response Schema is unintentionally overwritten by Test/Publish, with inconsistent behavior

Context:
In the HTTP Action config,  the Response Schema starts as an open/accept-all schema ({}). Running Test replaces this schema with whatever payload shape came back from that specific test call. If the user then hits Publish, that test-derived schema overwrites the previous (intentional) schema — with no confirmation or way to prevent it.

Problems:

1. No way to save/apply a schema independently of Publish
   There's currently no dedicated "Save Schema" or "Apply Schema" action. The only way a schema gets set is as a side effect of running Test, which is not obvious and easy to trigger by accident.
2. Publish silently overwrites the schema after a Test run
   • If a user runs Test (even just to check something) and then hits Publish, the schema from that one test call replaces whatever schema was previously defined — even if that test payload wasn't meant to become the new schema.
   • Since different test calls can return slightly different payload shapes, this makes it very easy to unintentionally wipe out a correct, working schema with an incomplete or one-off version.
3. Inconsistent schema behavior across repeated tests
   • Even with a schema already defined in the Response Schema section, results are inconsistent. Running the same test multiple times — with zero changes to the HTTP action or any republishing in between — sometimes returns the expected payload, and sometimes returns a null/empty response instead when ran from a conversational process for example.

Requested fix:

• Decouple schema updates from both Test and Publish — schema should only change when a user explicitly chooses to save/apply it or possibly links a data type to it.
• Add a clear "Save Schema" or "Apply Schema" action so users control when the schema is updated, rather than it happening automatically as a side effect of testing.
• Investigate the inconsistent null-response behavior on repeated test calls with no config changes — this points to something unstable outside of user action, not just a UI/schema issue.