Let a script apply element auto-numbering

useElementAutoNum(name)   select the current element numbering context
  numberElement(folio, el)  give one element its label from it

numberElement calls Element::setUpFormula(), the call the "add element"
tool makes right after placing an element, so a script gets the same
numbering: three coils numbered in turn are K1, K2, K3, and the counter
persists in the project (after a reload the next element is K3).

It is a separate call rather than a change to addElement(), which is
merged code: numbering what it places would change what an existing
script produces the moment its project happens to have a context selected.
A slave or a report is refused, since it takes its label from its master,
and so is a project with no context selected, instead of reporting a
success that did nothing.

setUpFormula() has a hazard for an element that is already placed. It
writes the label straight into the element's information and pushes only
the counter's advance onto the undo stack. Placing a new element hides
that, because undoing the placement removes the element; for an existing
one, a single undo rolled the counter back and left the label, so c3 stayed
"K3" while the counter went back to expecting K3 and the next numbering
would repeat a label it had forgotten. So the label it computed is taken,
the information put back, and the change pushed as a command inside the
same macro as the counter: one undo now reverts both, and renumbering c3
afterwards yields K3 again. Redo and the database agree.

Folio auto-numbering is deliberately not offered: in the application it
spawns whole new folios from a context, which is a different operation
from labelling. "Renumber existing conductors" has no equivalent to bind --
conductor numbering is applied when a conductor is created or moved, and
QElectroTech has no renumber-all action.

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

sources/scripting/qetscriptapi.h

@@ -177,6 +177,15 @@ class DynamicElementTextItem;
 	  because the application itself does it through direct project calls
 	  and only the counter advance is on the undo stack; the numbering
 	  actually applied to a conductor is.
+
+	  For elements, useElementAutoNum() selects the current context and
+	  numberElement() applies it to one element, as the "add element" tool
+	  does right after placing one. addElement() deliberately does not
+	  number what it places: doing it silently would change what an existing
+	  script produces the moment its project happens to have a context
+	  selected, so it is a separate, explicit call. Folio auto-numbering is
+	  not offered: in the application it spawns whole new folios from a
+	  context, which is a different operation from labelling.
 	- @b Images: place a picture from a file. The pixels are copied into
 	  the project, which stores them inline in the .qet -- the saved file
 	  does not refer to the original path, so it opens on another machine,
@@ -346,6 +355,8 @@ class QetScriptApi : public QObject
 		Q_INVOKABLE bool addAutoNum(const QString &kind, const QString &name, const QStringList &parts);
 		Q_INVOKABLE bool removeAutoNum(const QString &kind, const QString &name);
 		Q_INVOKABLE bool useConductorAutoNum(int folioIndex, const QString &name);
+		Q_INVOKABLE bool useElementAutoNum(const QString &name);
+		Q_INVOKABLE bool numberElement(int folioIndex, const QString &elementUuid);
 
 		// -- images, embedded in the project --
 		Q_INVOKABLE QStringList images(int folioIndex) const;