Adopt the QML-surface drift guard in lims, kanban and bank

[Yaraslaut]

Summary

QmlSurfaceAudit (examples/common/testkit/qml_surface.hpp, landed for #86)
is adopted by bookmarks, pastebin, polls and ledger. Three rungs with
QML still have no audit:

rung	QML files	bridges	guard today
lims	3	SampleBridge, ResultBridge	a loop over methodCount() in test_lims_qml_bridges.cpp; no per-name check
kanban	7	BoardBridge, ProjectAdminBridge	hand-written indexOfMethod/indexOfSignal lists + exact counts, in two files
bank	13	gui/controllers/*	none — the GUI has no test target at all

Adopting is a few lines per rung: bind each setInitialProperties alias to its
bridge instance and assert the audit is silent.

Why this is a separate issue

Two of the three are not mechanical:

• kanban asserts a conditional property count — test_board_qml_bridge.cpp
  checks propertyCount() - propertyOffset() == 7 or == 5 depending on a
  compile-time switch, so BoardBridge's QML-visible surface differs between
  configures. The audit has no notion of a conditional surface today; either
  the test binds different expectations per configure, or the audit needs one.
• bank builds its GUI as a standalone client with no tests/ target, so
  adopting means creating one, which is a larger change than adding an audit.

lims looks straightforward, and is the natural first one to do.

Verification status

Inferred from reading, on d6690c5 — the table above is a read of each
rung's test sources and gui/qml/ contents. No audit has been run against
lims, kanban or bank, so this issue makes no claim about whether those
rungs' surfaces actually agree with their QML. Note that the first run against
ledger immediately found 15 unbound members (#239), so a clean result should
not be assumed for any of these three.

What would change the verdict

Close when each of lims and kanban has a passing QmlSurfaceAudit case,
and bank either has one or has a recorded decision that its GUI stays
untested. Close early if QmlSurfaceAudit is withdrawn.