Fix scripting review findings: import, save, backups, timeout

Addresses scorpio810's review of PR #891:

- addElement() now imports the element into the project's own embedded
  collection first (QETProject::importElement()), same as the
  drag-from-collection-panel path -- otherwise the saved .qet referenced
  a definition outside the project, missing on another machine. Also
  found and fixed while wiring this up: ElementsLocation::setPath()
  forces any path to embed:// once a non-null project is passed, so the
  unconditional ElementsLocation(locationPath, m_project) this method
  used before silently broke every common://custom:// call. Refuses
  on an import-collision case that would otherwise reach
  QETProject::importElement()'s own modal ImportElementDialog, with
  nobody there to answer it in a script.
- addElement()/setElementPosition()/moveElement()/deleteElement() refuse
  on a read-only project, matching their GUI equivalents.
- save() goes through QETProject::write() when no path is given (read
  -only handling, saveddate/savedtime, QSaveFile via writeXmlFile()) and
  QET::writeXmlFile() directly for an explicit output path, instead of a
  plain QFile that skipped all of that.
- Interactive "Run Script...": exports briefly disable project backups
  around the temporary QETProject CLIExport::run() opens on the same
  file, so it doesn't race the real open project's own KAutoSaveFile.
  Restored right after -- the headless --run path is untouched, since it
  depends on backups staying off for the whole run.
- A watchdog thread now calls QJSEngine::setInterrupted() after 30s,
  so a runaway script (`while(true){}`) can't freeze the GUI or hang a
  CI job forever. First version used sleep_for() and blocked every run,
  fast ones included, for the full 30s on join() -- caught by testing a
  one-line script, fixed with wait_for() on a condition variable so a
  script that finishes early wakes the watchdog immediately.
- Interactive script errors now also show a QetMessageBox, not just
  stderr (invisible on Windows).
- Ran update_translations (lupdate) to pick up the 37 strings this
  feature had not yet added to the .ts files.

Not applied: wrapping the whole script run in one undo macro. It would
make the script's own qet.undo()/qet.redo() calls silent no-ops for the
run's duration -- QUndoStack ignores undo()/redo() while a macro is
open -- which would break that already-shipped, explicitly requested
capability to get one convenience Ctrl+Z instead.

Verified: Qt 6.10.2, builds clean, ctest 6/6. Ran each fix against a
real project: addElement() on a common:// path now succeeds and the
saved file embeds the definition (embed://import/...); read-only
project refuses addElement(); save("") and save(otherpath) both
produce a correctly embedded file; `while(true){}` under --run is
interrupted at 30s where it previously hung forever, and a normal
script now exits in ~0.3s instead of blocking for the full timeout
budget.

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

sources/scripting/qetscriptapi.h

@@ -54,7 +54,14 @@ class Element;
 	  the standard `pos` property for moves, DeleteQGraphicsItemCommand for
 	  removal) -- Ctrl+Z undoes a script's edits exactly as it would the
 	  equivalent manual ones, because they are, mechanically, the same
-	  commands on the same stack. One consequence worth knowing, not a bug:
+	  commands on the same stack. All four refuse on a read-only project,
+		  same as their GUI equivalents check Diagram::isReadOnly() before
+		  editing. addElement() also imports the element into the project's
+		  own embedded collection first (QETProject::importElement()), same
+		  as the drag-from-collection-panel path -- without it, the saved
+		  file referenced a definition outside the project and went missing
+		  on a machine without that same collection installed. One
+		  consequence worth knowing, not a bug:
 	  QPropertyUndoCommand merges consecutive commands on the same
 	  object+property when their text() also matches
 	  (QPropertyUndoCommand::mergeWith(), pre-existing), and
@@ -76,7 +83,11 @@ class Element;
 	Every method here is either non-blocking by construction or, for
 	messages, safe under QET::QetMessageBox's existing non-interactive mode
 	(already active for headless runs). Nothing here opens a dialog the
-	caller has to wait on.
+	caller has to wait on -- including addElement(), which detects an
+	import-collision case that would otherwise reach
+	QETProject::importElement()'s own ImportElementDialog::exec() and
+	refuses instead, rather than let a plain QDialog (not routed through
+	QetMessageBox) block a script the same way.
 */
 class QetScriptApi : public QObject
 {