Let a script list, embed and apply a folio's title block template

titleBlockTemplates()          embedded + common/company/custom, by name
  embedTitleBlockTemplate(name)  copy one into the project's own collection
  setFolioProperty(f,"template",name)  embed-if-needed, then apply
  folioProperty(f,"template")

Not the trivial addition to the existing title-block-field list it looked
like at first. Diagram::setTitleBlockTemplate() resolves a name only
against QETProject::embeddedTitleBlockTemplatesCollection() -- the exact
same copy-into-the-project step addElement() already goes through for
elements, and for the same reason: a project opened on another machine
must not depend on files only this one has. embedTitleBlockTemplate()
does that copy through get/setTemplateXmlDescription(), the same round
trip the template editor itself uses to save one -- not scripting-specific
code, and unlike defining an auto-numbering context, not undoable, for the
same reason that isn't: the application does both through direct
collection/project calls with no undo command of their own.

Two things found only by testing, not by reading:

- "default" is a real template name in the common collection, and setting
  a folio's template to it is legitimate -- but
  BorderTitleBlock::titleBlockTemplateName() normalises a template
  literally named "default" back to "", indistinguishable from no
  override, since that is genuinely what "no override" renders with. The
  first version compared the raw name and reported success as failure;
  fixed by comparing against that same normalised form, which folioProperty()
  now also documents.
- QElectroTech resolves the common template collection from a compiled-in
  path (here, an absolute /usr/share/qelectrotech/titleblocks, not
  relative to the binary), and --common-tbt-dir, the CLI override, is
  read by QETApp::parseArguments() -- which the --run headless path never
  reaches, confirmed by the CLI itself swallowing the flag as a stray
  positional argument. There is no QSettings fallback the way
  commonElementsDir() has. So testing this at all needed the path to
  genuinely exist; no environment trick from inside the process reaches
  it.

Verified: 10 common templates listed; DIN_A4 embedded and applied,
folioProperty reading it back; re-applying the same name a no-op success;
an unknown name refused; "default" applied and correctly read back as ""
per the note above; both folios exported to PNG and visually compared --
plain default rendering vs. DIN_A4's logo, revision table and field
layout, genuinely different, not just an API call returning true. The
choice survives a save and reload. Qt 6.10.2, ctest 12/12, coherence gate
clean.

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

sources/scripting/qetscriptapi.h

@@ -211,6 +211,27 @@ class DynamicElementTextItem;
 	  the folio properties panel offers; the title block's header sizes,
 	  which it does not, are left alone. Changing the project title is not
 	  undoable: the application sets it directly too.
+
+	  A folio's title block @b template is a seventh, separate case:
+	  Diagram::setTitleBlockTemplate() resolves a name only against
+	  QETProject::embeddedTitleBlockTemplatesCollection() -- the same
+	  copy-into-the-project step addElement() already does for elements,
+	  and for the same reason (a project opened on another machine must not
+	  depend on files only this one has). titleBlockTemplates() lists what
+	  is embedded and what is available to embed from the common/company
+	  /custom collections, each name suffixed with its source;
+	  embedTitleBlockTemplate() does the copy (QDomElement in, unmodified,
+	  via *TemplatesCollection::get/setTemplateXmlDescription() -- neither
+	  side is scripting-specific code, both already exist for the template
+	  editor to call). setFolioProperty(folio, "template", name) then
+	  embeds it first if it is not already, refusing only if no collection
+	  has that name at all. Embedding is not undoable, the same as defining
+	  an auto-numbering context is not: the application does both through
+	  direct collection/project calls with no undo command of their own.
+	  A template literally named "default" reads back as folioProperty()
+	  "" afterwards, not "default": BorderTitleBlock::titleBlockTemplateName()
+	  treats the two as the same thing, since "no override" already renders
+	  with the template named "default".
 	- @b Geometry and folio order: elementGeometry() reads where an element
 	  is -- x, y (its origin), rotation, and the box it occupies on the folio
 	  (left, top, right, bottom) -- so a script can lay one thing out relative
@@ -418,6 +439,10 @@ class QetScriptApi : public QObject
 		Q_INVOKABLE QString folioBorder(int folioIndex, const QString &property) const;
 		Q_INVOKABLE bool setFolioBorder(int folioIndex, const QString &property, const QString &value);
 
+		// -- title block templates: which exist, embedding one into the project --
+		Q_INVOKABLE QStringList titleBlockTemplates() const;
+		Q_INVOKABLE bool embedTitleBlockTemplate(const QString &name);
+
 		// -- read an element's geometry --
 		Q_INVOKABLE QVariantMap elementGeometry(int folioIndex, const QString &elementUuid) const;