Complete the plugin settings removal after the feat/plugin-feature merge

The merge kept this branch's PluginConfig design, which deletes
PluginDescriptor::settings, get_plugin_settings() and ctx.params, but left
references to them behind: the slic3rutils target did not build, and the
bindings test still asserted the removed ctx.params attribute.

Port the two settings tests onto PluginConfig instead of dropping them. They
guard a field bug where a cloud-metadata refresh wiped a plugin's settings and
it silently ran on its own defaults, so the equivalent properties are still
worth pinning: that a stored config survives the refresh, and that an edited
config reaches the plugin through a real dispatch.

Also defer PluginsConfigDialog's web commands off the webview script-message
callback, as PluginsDialog already does. Its remove_preset_override handler put
a modal wxMessageBox on that stack, which is the GTK crash class fixed in
b779a7bfed/f2ccbfc8b5 for the sibling dialog.

src/slic3r/GUI/PluginsConfigDialog.cpp

@@ -42,7 +42,7 @@ PluginsConfigDialog::PluginsConfigDialog(wxWindow* parent, Preset::Type type, co
                    wxSize(640, 520));
 }
 
-PluginsConfigDialog::~PluginsConfigDialog() = default;
+PluginsConfigDialog::~PluginsConfigDialog() { m_alive->store(false, std::memory_order_release); }
 
 const Preset* PluginsConfigDialog::current_preset() const
 {
@@ -70,6 +70,18 @@ void PluginsConfigDialog::on_script_message(const nlohmann::json& payload)
     if (handle_common_script_command(payload))
         return;
 
+    // Defer command handling out of the webview script-message callback, exactly as PluginsDialog
+    // does: GTK and macOS deliver it synchronously inside the native webview callback, and window
+    // work on that stack is the crash class fixed in b779a7bfed/f2ccbfc8b5. remove_preset_override
+    // puts a modal message box on that stack, which is the same bug.
+    wxGetApp().CallAfter([this, alive = m_alive, payload]() {
+        if (alive->load(std::memory_order_acquire))
+            handle_web_command(payload);
+    });
+}
+
+void PluginsConfigDialog::handle_web_command(const nlohmann::json& payload)
+{
     const std::string command = payload.value("command", "");
     if (command == "request_capabilities") {
         send_capabilities();

src/slic3r/GUI/PluginsConfigDialog.hpp

@@ -4,6 +4,8 @@
 #include <libslic3r/Preset.hpp>
 #include <slic3r/plugin/PluginConfig.hpp>
 
+#include <atomic>
+#include <memory>
 #include <string>
 
 namespace Slic3r { namespace GUI {
@@ -25,6 +27,8 @@ public:
 
 private:
     void on_script_message(const nlohmann::json& payload) override;
+    // Runs one web command on a clean main-loop stack; see on_script_message.
+    void handle_web_command(const nlohmann::json& payload);
 
     const Preset* current_preset() const;
     void          send_capabilities();
@@ -41,6 +45,8 @@ private:
     // Set when the preset's stored text could not be parsed: the rows are shown read-only rather
     // than silently replacing data we did not understand.
     std::string               m_parse_error;
+    // Guards the deferred command handlers against the dialog being destroyed while one is queued.
+    std::shared_ptr<std::atomic<bool>> m_alive = std::make_shared<std::atomic<bool>>(true);
 };
 
 }} // namespace Slic3r::GUI

src/slic3r/GUI/PluginsDialog.cpp

@@ -483,8 +483,9 @@ void PluginsDialog::on_script_message(const nlohmann::json& payload)
     // Defer command handling out of the webview script-message callback: GTK and macOS
     // deliver it synchronously inside the native webview callback (see ui_create_window
     // in PluginHostUi.cpp), and window work on that stack is the crash class fixed in
-    // b779a7bfed/f2ccbfc8b5. Deferring at this single entry point keeps every command
-    // handler, current and future, off that stack by construction.
+    // b779a7bfed/f2ccbfc8b5. Deferring here keeps every command handler in THIS dialog off
+    // that stack; it is not a guarantee for other WebViewHostDialog subclasses, which each
+    // have to defer for themselves (PluginsConfigDialog does; others still do not).
     wxGetApp().CallAfter([this, alive = m_alive, payload]() {
         if (alive->load(std::memory_order_acquire))
             handle_web_command(payload);

src/slic3r/GUI/PostProcessor.cpp

@@ -270,9 +270,6 @@ static void run_post_process_plugins(const ConfigOptionStrings& capabilities,
         ctx.host         = host;
         ctx.output_name  = output_name;
         ctx.full_config  = &config;   // no live Print here; config_value() reads this
-        // Hand the plugin its own [tool.orcaslicer.plugin.settings] as ctx.params (same plugin_key the
-        // capability was resolved by), mirroring the in-pipeline dispatcher in GUI_App.cpp.
-        const std::string plugin_key = ref.uuid.empty() ? ref.name : ref.uuid;
 
         ExecutionResult exec_result;
         try {