Extract set-signal-type into core; add it to the wx GUI.

Fourth editing op into the wx frontend. Extract the type-name parse + apply
into core/app/edit.hpp::set_signal_type(Signal*, name) -> {ok, error, type},
failing without mutation on an unrecognised name. The interactive sigtype modal
keeps its own SignalType-cycling path (different interaction, trivial mutation).

The TUI `set-signal-type` command now renders that result (output unchanged).
The wx GUI gains Edit ▸ Set signal type…: a shared PickModule() helper (PickPart
now builds on it) + inline signal choice + a power/gnd/other dropdown, then the
core op, logged as "module/signal: signal type = …" and reflected.

tests/test_edit.cpp: name parsed and applied; unknown name refused without
mutation. 387 core assertions green; tui + wx build clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

src/core/app/edit.hpp

@@ -1,9 +1,12 @@
 #ifndef _APP_EDIT_HPP_
 #define _APP_EDIT_HPP_
 
+#include "core/domain/signal_type.hpp"  // SignalType
+
 #include <string>
 
 class Part;
+class Signal;
 
 // Application layer: UI-independent part-editing operations any frontend can
 // call. No console, no dialogs, no FTXUI — Part in, result struct out.
@@ -38,6 +41,17 @@ struct AttachBsdlResult {
 // when the file cannot be parsed.
 AttachBsdlResult attach_bsdl(Part *part, const std::string &path);
 
+// Outcome of overriding a signal's type from a user-supplied name.
+struct SetSignalTypeResult {
+    bool ok = false;
+    std::string error;                 ///< set when the name isn't power/gnd/other
+    SignalType type = SignalType::Other;  ///< the resolved type (for rendering)
+};
+
+// Set `sig`'s type from `type_name` (power | gnd | other, case-insensitive).
+// Fails (ok=false, error set, no mutation) on an unrecognised name.
+SetSignalTypeResult set_signal_type(Signal *sig, const std::string &type_name);
+
 }  // namespace app
 
 #endif  // _APP_EDIT_HPP_