forms: every DynamicForm warns about onOptionsReceived on any controller without a Choice field

[Yaraslaut]

DynamicForm.qml:1092-1129 declares one Connections block on the controller
with two handlers:

Connections {
    target: form.controller
    function onReplyReceived(actionType, ok, payload) { ... }
    function onOptionsReceived(optionsAction, ok, payload) { ... }
}

optionsReceived only exists on a controller that serves a
morph::forms::Choice field. A controller that serves none does not declare it
— and deliberately does not: bookmarks::gui::BookmarkFormsController's own
doc comment has a "No fetchOptions()" section saying that adding one with
nothing to call it "would be a stub with nothing to call it"
(examples/bookmarks/gui_lib/bookmark_forms_controller.hpp:62-69), and
PasteFormsController is cited there as the same case.

So the sanctioned shape produces a QML warning, once per form instance, as soon
as a real controller is attached:

qrc:/qt/qml/MorphForms/qml/DynamicForm.qml:1093:5: QML Connections: Detected
function "onOptionsReceived" in Connections element. This is probably intended
to be a signal handler but no signal of the target matches the name.

Verification status: reproduced

Measured at 1f7a4619 (branch scenario-corpus-both-axes), Qt 6.11.2,
QT_QPA_PLATFORM=offscreen, on a
-DMORPH_BUILD_FORMS_QML=ON -DMORPH_BUILD_LADDER=ON -DMORPH_LADDER_RUNGS=kanban
configure. It appears when examples/kanban's ProjectListView/BoardView are
loaded into a QQmlApplicationEngine with a live ProjectAdminBridge /
BoardBridge as an initial property — the new
examples/kanban/tests/test_gui_forms_render.cpp does exactly that, and had to
grow an explicit tolerance for this one warning text to keep its
"no other warning" assertion.

Why nobody has hit it before: every rung's rule-6 smoke test
(examples/TESTING.md) loads its roots with all controllers null. A
Connections block with a null target matches nothing and warns about
nothing, so the warning is invisible to the one QML test each rung ships.

Not verified: whether the desktop clients emit it at runtime. Inferred yes,
from the same code path (ladder_kanban_gui writes to stderr and I did not
capture per-warning output from a real session); not measured.

Why it matters beyond noise

The rung smoke tests assert "the engine emitted zero QML warnings" — that is the
whole assertion. The moment any rung tests a form against a real controller,
that assertion has to be weakened to "zero warnings except this one", which is
exactly the kind of tolerance that later swallows a real warning. It also means
a shipped, correct, documented controller shape cannot produce a clean log.

A shape for the fix

Either ignoreUnknownSignals: true on that block (the Qt-idiomatic answer for
an optional signal), or split the two handlers into two Connections blocks so
replyReceived — which every controller has — is unaffected. The second is
probably better: it keeps an actually-misspelled onReplyReceived loud.

What would change the verdict

Close when loading a form with a controller that serves no Choice field emits
no QML warning, with the assertion made by a test that fails without the fix
(the kanban test above can drop its tolerance and become that regression check).

[Yaraslaut]

Triage: rescope — the problem is real and wider than stated; the recommended fix does not close it

Premise: confirmed, independently. Reproduced with no morph code — a QML object declaring only replyReceived, with the DynamicForm Connections shape attached (Qt 6.11.2, bare QQmlEngine):

======== A: combined block (the shipped shape) ========
A.qml:5:26: QML Connections: Detected function "onOptionsReceived" in Connections element.
This is probably intended to be a signal handler but no signal of the target matches the name.

The blast radius is every shipped rung, not just bookmarks and pastebin

There is no shared controller base class — each rung hand-writes its own:

$ grep -rn "void replyReceived" examples/ src/        ->  9 classes
$ grep -rn "void optionsReceived" examples/ src/      ->  1 class
examples/forms/gui_qml/FormsController.hpp:96:    void optionsReceived(...)

Exactly one QObject in the tree declares optionsReceived, and it is the examples/forms demo controller. The other eight (bookmarks::gui::FormsBridge, kanban's ProjectAdminBridge, lims' ResultQmlBridge/SampleQmlBridge/SamplePresenter/ResultPresenter, pastebin's and polls' bridges) do not. Against 18 controller: bindings across five shipped rungs' QML, every one of them attaches a target that warns. The title is accurate; the body understates it.

The recommended fix does not work

Four variants, same harness:

variant	shape	result
A	one block, both handlers (today)	warns
B	split into two blocks (the issue's preferred fix)	still warns — B.qml:9:27, on the options-only block
C	split + ignoreUnknownSignals: true on the options-only block	silent
D	C's shape, with onReplyRecieved misspelled in the un-ignored block	warns — D.qml:5:27
E	one block + ignoreUnknownSignals: true, with onReplyRecieved misspelled	silent — the misspelling is swallowed

So neither alternative as written is right. B alone leaves the warning exactly where it is: a Connections block warns per unmatched handler, and splitting only moves which block reports it. A alone (option 1, ignoreUnknownSignals on the combined block) does silence it, but variant E shows it costs precisely what the issue wanted to keep — a misspelled onReplyReceived goes quiet too.

The fix is the union: split the handlers, and put ignoreUnknownSignals: true on the onOptionsReceived block only. Variants C and D show that shape is silent for a controller with no Choice field and still loud for a misspelling on the signal every controller has. Rewrite the "shape for the fix" section around that before anyone builds it, because "the second is probably better" as written would be implemented, tested against the close condition, and fail it.

Everything else stands: the bookmarks doc comment says what is quoted (bookmark_forms_controller.hpp, "@Par No fetchOptions()"), and the "why nobody has hit it" explanation — rung smoke tests load their roots with controller: null, and a null-target Connections matches and warns about nothing — is right.

What would change this verdict: a run of variant B on a real controller showing no warning. Mine warns at B.qml:9:27.