lims, kanban: adopt the QML-surface drift guard, and stop the audit flagging guarded optional reads

[Yaraslaut]

Adopts QmlSurfaceAudit in lims and kanban — two of #240's three remaining
rungs. bank is left for its own PR: its GUI has no test target at all, so
adopting there means creating one.

Why a count was not enough

Both rungs already guarded their bridges by hand, and both guards had the same
blind spot: neither ever reads a .qml file. lims loops over
methodCount(); kanban keeps indexOfMethod/indexOfSignal lists plus an
exact propertyCount() - propertyOffset() assertion.

Those catch a deletion. But a count is not a name — it stays satisfied when one
invokable is renamed and another added, which is precisely the drift QML
suffers. QML binds by string, so a renamed invokable, or a Connections
handler for a signal that no longer exists, is not a compile error, not a test
failure, and not a QML warning. The pane simply stays empty.

The interesting part: the bug was in the audit, not in kanban

The audit reported BoardView.qml as reading a property BoardBridge does not
have. The QML is correct and the audit was wrong.

deadLetterCount exists only under MORPH_BUILD_OFFLINE_SQLITE, and the view
guards its dead-letter banner with deadLetterCount !== undefined exactly so
the binding stays hidden without it — the header's own comment says so. A read
of that shape is a question about whether conditionally-compiled surface is
present, not a use of it. Reporting it was backwards: the only way to satisfy
the audit would have been to delete the guard that makes the binding safe.

So a read compared against undefined (or under typeof) is now understood as
a probe, scoped to the probing file.

This also changes what #240 called the blocker, though not as cleanly as I
first wrote. The issue framed kanban's conditional surface as needing "the
audit to have a notion of a conditional surface", because the hand-written
guard asserts == 7 or == 5 depending on the switch. A per-name check does
not have that problem — it reads the metaobject that was actually built, so
an absent property is simply absent.

But the exemption list does need a branch, and an earlier version of this PR
claimed otherwise. queueDepth exists only under MORPH_BUILD_OFFLINE_SQLITE
and is unbound in the configure where it exists — BoardView.qml binds
deadLetterCount and reads queueDepth nowhere. So it is a tenth backlog
entry visible in one configure only, and its exemption carries the same
#ifdef as the property.

CI caught that; my local run could not, because it had the switch off. Worse,
the two-configure comparison I based the original claim on was one I had
already found unsound — its grep matched only the bridge-to-QML direction and
dropped the QML-to-bridge findings — and I carried the conclusion forward
regardless.

Re-verified in a fresh build directory per configure, which the first
attempt was not: reconfiguring OFF → ON does not reliably re-run AUTOMOC, so
the bridge kept a metaobject without queueDepth while its compile line
carried the macro. Fresh ON: surface test 46 assertions, audit green. Fresh
OFF: green.

Mutation evidence

A narrowing rule can only silence findings, never create them — which makes it
exactly the kind of change that can quietly gut a guard. So it was tested both
ways rather than assumed:

tree	findings
guard stripped from BoardView.qml	2 reported
guard restored	0

The audit's own suite (17 cases, 77 assertions) passes unchanged.

Backlogs, recorded rather than swallowed

#240 warned that a clean result should not be assumed for any rung, and it was
right — both found one on the first run:

• lims: 15 members → lims: two QML bridges publish 15 members no gui/qml file binds #287
• kanban: 9 members → kanban: BoardBridge publishes nine members no gui/qml file binds #291

Neither is a broken screen; the other direction is clean in both. Each member
is either dead surface or a missing control, and deciding which is per-member
work these files do not do. They are itemised the way ledger's already are
(#239), so the guard goes live now and catches the next drift instead of
waiting for the backlog to clear. Both lists are checked in both directions —
an exemption for a member since deleted, or one QML has since bound, fails the
test — so they can only shrink deliberately.

One of kanban's nine is listed under protest and argued in #291:
syncStatusChanged is the NOTIFY behind deadLetterCount, which
BoardView.qml does bind. A property binding consumes a NOTIFY signal
without an explicit handler and the audit does not model that. Teaching it to
would change what ledger's list means too, so it is recorded rather than
fixed in passing.

Verification

• lims audit: green. kanban audit: green.
• Audit's own suite: 17 cases / 77 assertions, unchanged.
• Probe rule mutation-tested in both directions (table above).
• clang-format silent; check_spec_citations.sh green.

The four existing adopters, re-run against this change — the regression
that a narrowing rule most plausibly breaks. This was still building when the PR
was opened; it has since finished, all green:

rung	result
bookmarks	224 assertions / 13 cases
pastebin	189 assertions / 8 cases
polls	106 assertions / 7 cases
ledger	2 assertions / 1 case

(pastebin, bookmarks and polls tag their audit [qml-bridges] rather than
[qml-surface], so the figures above cover their whole bridge suite. ledger
and the two rungs added here use [qml-surface]. That inconsistency predates
this PR and is left alone.)

Advances #240 (lims, kanban; bank remains) and, with it, the last open item
of #86 — whose other two justified helpers, #168 and #169, are already closed.

[codecov]

Codecov Report

❌ Patch coverage is 63.63636% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
examples/common/testkit/qml_surface.cpp	63.63%	0 Missing and 4 partials ⚠️

📢 Thoughts on this report? Let us know!