Add MDIPane and Dock pages; generate the item and option tables
MenuBar, TabTrinket, Separator, Spacer; ledger correction on ListView MenuBar covers all three types that build a bar, and leads with the thing that catches people: a menubar is a TOP-LEVEL object adopted as the connection's chrome, not a child of a window. Also that every item raises `command` whether or not it has an action= -- one without gets a generated cmd.auto.N and that is what arrives -- and that `&` mnemonics are menu-only, with && the escape. TabTrinket, Separator and Spacer complete the simple end. Two corrections came out of running them rather than reading them: a separator does NOT take its direction from the box it sits in (it is horizontal until told otherwise, so an hbox needs orientation=vertical), and spacer has width/height for a fixed gap as well as stretch for an elastic one. ListView's appearance section was wrong. alternate_rows and ledger are the same switch -- both write one field, and the paint path bands with the ledger colors either way -- so they do not combine, and `ledger !alternate_rows` comes out off. The page now says so and points at ledger as the name to prefer. Every executable example across all fourteen pages was run against the real registry: 41 clean, 2 deliberate error demos, 5 structural skeletons left elided on purpose.
Templates and Aliases, and point the pages that needed it at it The wire language has template and alias verbs sitting beside new/set/ destroy, and nothing on the wiki mentioned them. Worse, ListView and ComboBox taught a workaround for a problem templates solve. A template's children are applied before any instance's properties, so template Sizes=listview children={...three items...} lv=new Sizes selected=2 selects the third row, while the same properties in one statement out of order silently select the first. ListView and ComboBox now lead with that and keep the manual ordering rule as the single-statement case. Panel gains a FormRow example, since a layout built more than once is what templates are for. The new page covers what running the code showed: instance properties override the template's, templates chain with the more specific winning, template children come first and instance children are appended to them, and keys inside a template body are namespaced under the instance key and surfaced with key=path. Also the D18 naming rule and every rejection it produces, each one run rather than assumed. Two examples were wrong before this landed. font_size=20 came from a session test that uses a mock factory accepting any property; against the real registry a button has no font_size, so a reader pasting it would get an error. And the appended-children example omitted its own template declaration. Both found by executing the examples rather than parsing them -- parsing had passed.