docs: require Vue views, Pinia stores and the kit for new UI

CONTRIBUTING gains a Building UI section: new UX elements are Vue
components rendering a Pinia store their owner publishes to, portable
owners stay framework-free behind a publish option, controls come from
src/ui/kit first, controllers don't bind the DOM by hand (Teleport where a
view renders elsewhere; body classes, focus, same-task measured positions
and painted surfaces stay imperative), text goes through t()/tn() with
msg() for stored English, and tests mount components. The README and the
architecture summary drop the stale vanilla-JS claim, the UI ownership doc
points to the guide, and the migration doc's UiPanel note names
v-panel-state as what draws a panel's collapse.

docs/VUE-MIGRATION.md

@@ -48,9 +48,9 @@ existing stylesheet and custom properties; a kit class such as
 `ui-button--icon` carries no Core style yet, and a converted control keeps
 its own classes beside it. They contain no application state.
 `UiPanel` takes ui-vue's `title`, slots and `v-model:collapsed`, but its
-`collapsed` drives only the button and `ui-panel--collapsed`: the panel's
-owner hides the body by writing the root's `collapsed` class at once, and
-there is no `closable`, since Core's panels collapse rather than close.
+`collapsed` drives only the button and `ui-panel--collapsed`: the root's
+`collapsed` class, which hides the body, is drawn at once by `v-panel-state`
+from the panel chrome store, and there is no `closable`, since Core's panels collapse rather than close.
 `UiSegmented` adds `keyboard` (`none`, `arrows` as in ui-vue, or `radio` with
 Home and End), since each of Core's groups keeps its own keyboard policy, and
 `itemClass`/`activeClass` for Core's segment classes. A key moves focus at