kanban: two screens still cite morph#386 as a live rule-2 justification after it was fixed

[Yaraslaut]

morph#386 is fixed: DynamicForm now draws a oneOf-of-consts enum as a
combo box and refuses a value outside the set. The kanban rung is the place
that recorded the gap, and four of its files still assert it as a present-tense
fact.

What now says something false

• examples/kanban/README.md, "morph subsystems exercised" — the rule-2
  justification table:

  | `gui/qml/MembersView.qml`'s role pickers (`:70`, `:101`) | `SetMemberRole` | **(a).** The renderer cannot draw an `enum class`. [#386] |
  | `gui/qml/RulesView.qml`'s add-rule row (`:105`, `:113`) | `CreateRule` | **(a).** Same enum gap. [#386] |
  

  and the paragraph under it: "DynamicForm renders that as a plain
  TextField … so they stay until [forms: DynamicForm renders a C++ enum class as a free-text field, and its gate accepts values outside the set #386] lands."

• examples/kanban/gui/qml/MembersView.qml:12-24 — "the shipped DynamicForm
  renders that as a plain free-text field … it stays until morph#386 lands.
  Everything else about this view is already schema-shaped and converts in one
  step once it does."

• examples/kanban/gui/qml/RulesView.qml:14-28 — the same, for
  CreateRule::mutationType, plus: "Converting this view is therefore one enum
  fix plus one DTO field type."

• examples/kanban/gui_lib/kanban_schemas.hpp:30-38 — the "What is
  deliberately absent" doc comment: SetMemberRole and CreateRule are kept
  out of the schema document because "the shipped DynamicForm renders [a
  closed oneOf of consts] as a free-text field, accepting and
  submitting any string at all."

Each of those is a statement about the framework, not about kanban, and each is
now wrong. examples/IMPLEMENTATION.md rule 2 requires justification (a) to
name a filed gap; the gap it names is closed, so the justification no longer
holds and the two screens should convert.

What the conversion is

SetMemberRole is ready as-is: three members, one of them the enum the fix now
draws. CreateRule needs one more decision the rung's own comment already
records — triggerColumnId is a user-chosen foreign key, which rule 3 says
should be a morph::forms::Choice<…, "GetBoardState"> rather than a raw id.
That is a DTO change, not a renderer one.

Both actions then join kanban_schemas.hpp's document, and
tests/test_gui_forms_render.cpp — which already drives each converted form in
a real QML engine over a real backend and asserts the controls drawn, the body
assembled and the row written — gains two cases.

Verification status: inferred from reading, not run

Measured: the morph#386 fix, in the branch that closes it, renders
schemaJson<kanban::SetMemberRole>()'s role as a ComboBox with the three
Viewer/Member/Manager rows and leaves the form !ready for
role = "Emperor" — src/qt/forms/tests/tst_DynamicFormEnumChoice.qml pins
that against the schema pasted verbatim from schemaJson<>().

Not verified: I did not build or run either kanban screen against the
fixed renderer, and did not attempt the conversion. The claim here is only
that the four passages above are now false and that the rule-2 justification
they support has lapsed.

Not verified: whether GetBoardState's reply shape actually satisfies
Choice's option-row extraction for triggerColumnId. RulesView.qml's own
comment asserts it returns columns as its first array member; I did not
check.

What would close this

Both screens rendering through DynamicForm, both actions in
kanban_schemas.hpp, test_gui_forms_render.cpp covering them, and the four
passages above rewritten or deleted. Re-open if a rung again cites a closed
issue as a live justification under rule 2.

[Yaraslaut]

Triaged: triage: valid.

Verified every factual claim against current origin/master:

• morph#386 is genuinely fixed and merged: e675253a/3abd73b7 ("forms:
  draw a schema-stated closed set as a picker, and gate on it (forms: DynamicForm renders a C++ enum class as a free-text field, and its gate accepts values outside the set #386)").
  src/qt/forms/qml/DynamicForm.qml now has explicit enumChoices() /
  oneOf-of-consts handling (lines ~248-380), not the old
  first-non-null-branch collapse. The issue references its own regression
  QML (tst_DynamicFormEnumChoice.qml) as pinning this; consistent with what's
  in the tree.
• All four cited stale passages exist verbatim as quoted:
  examples/kanban/README.md:180-181 (rule-2 justification table) and
  :190-192 (the "stay until forms: DynamicForm renders a C++ enum class as a free-text field, and its gate accepts values outside the set #386 lands" paragraph),
  examples/kanban/gui/qml/MembersView.qml:15,23,
  examples/kanban/gui/qml/RulesView.qml:16, and
  examples/kanban/gui_lib/kanban_schemas.hpp:38. Found one more instance of
  the same staleness the issue didn't enumerate —
  examples/kanban/README.md:325's findings list still says forms: DynamicForm renders a C++ enum class as a free-text field, and its gate accepts values outside the set #386 "is what
  keeps MembersView/RulesView hand-built" in the present tense — filing
  this only as confirmation of the same finding, not a new issue, since it's
  the identical staleness the ticket is already about.
• The proposed conversion is technically sound:
  SetMemberRole (examples/kanban/include/kanban/dto/project_dto.hpp:44-47)
  is exactly ProjectId, std::string, Role role — three members, one the
  enum forms: DynamicForm renders a C++ enum class as a free-text field, and its gate accepts values outside the set #386 now draws, nothing else blocking it.
  CreateRule (examples/kanban/include/kanban/dto/rule_dto.hpp:111-121) has
  triggerColumnId as a bare ColumnId, confirming it needs the DTO change
  (wrap as morph::forms::Choice<..., "GetBoardState">) in addition to the
  enum fix — Choice is a real, existing primitive
  (include/morph/forms/choice.hpp:85) and rule 3
  (examples/IMPLEMENTATION.md:279) is a real, existing rule, so the
  prescribed direction isn't inventing anything.
• Checked the issue's own flagged "not verified" claim — whether
  GetBoardState's reply shape satisfies Choice's option-row extraction for
  triggerColumnId: GetBoardResult
  (examples/kanban/include/kanban/dto/board_dto.hpp:177-184) is
  projectId, name, then columns as its first std::vector member —
  exactly what RulesView.qml's own comment claims. So even the part the
  issue explicitly declined to verify turns out to hold.

Nothing here contradicts any part of the issue; every quoted passage, cited
line number, and DTO shape checked out exactly. area: ladder was already
applied and is the right area (this is about the kanban rung's own docs/QML
comments, not core framework docs). Adding triage: valid — the fix direction
(convert both screens, add the two test_gui_forms_render.cpp cases, retire
the four-plus stale passages) is correct as written and needs no rescoping
before someone implements it.