Fix #527: use ApplicationModal for Project Properties to prevent SIGSEGV

ProjectPropertiesDialog::exec() was using Qt::WindowModal, which only
blocks the parent ProjectView window.  The MDI workspace and its other
subwindows remained interactive, so actions like new_project or
close_project could fire while the dialog's config pages still held raw
QETProject* pointers — leading to a SIGSEGV when Qt's event loop later
dispatched a signal through one of those stale pointers.

Detected by the 8-hour GUI fuzzer: action sequence add_diagram_page →
flood_wires ×18 → new_project while Project Properties was open
produced exit code -11 (SIGSEGV) on the first of 12,717 actions.

Switch to Qt::ApplicationModal so no window can receive input while the
dialog is open.  Project Properties is a short-lived dialog; blocking
the whole application for its duration matches user expectation and
removes the lifetime hazard without requiring QPointer surgery across
four config-page classes.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

sources/ui/projectpropertiesdialog.cpp

@@ -63,7 +63,13 @@ ProjectPropertiesDialog::~ProjectPropertiesDialog ()
 */
 void ProjectPropertiesDialog::exec()
 {
-	m_properties_dialog->setWindowModality(Qt::WindowModal);
+	// ApplicationModal (not WindowModal) so no other window — including other
+	// MDI subwindows — can dispatch events while the dialog holds raw
+	// QETProject* pointers in its config pages.  WindowModal only blocks the
+	// parent ProjectView; the rest of the MDI area stays live, which allowed
+	// new_project / close_project to replace the project under the dialog
+	// and cause a SIGSEGV.  See issue #527.
+	m_properties_dialog->setWindowModality(Qt::ApplicationModal);
 	m_properties_dialog -> exec();
 }