Application, StatusBar, ScrollArea
Filling the three names the reorganised index introduced.
Application is the odd one: the connection itself, seen from the display's
side. It is never built with `new` -- the handshake reports the id of the
instance that already exists, and a client addresses it with
`set <appID> ...`. It takes no children, has no generated table because it
is not a registered trinket type, and has three properties. Two of them
matter beyond themselves: multiwindow gates whether a client may create
type="normal" windows at all (and earns a free Window menu with
Tile/Cascade), and name is authorization-gated -- the name a connection
was approved under is the only one it may keep, unless the display marked
its trust as name-independent.
StatusBar is three types, statusbar/section/span, and top-level chrome
like a menu bar rather than a window child. Its `align` is three-valued
where the common one is seven, so align=middle is rejected; spans take
precedence over a section's own text.
ScrollArea holds one content trinket, and `resizable` decides whether
content re-wraps to the viewport or scrolls sideways.
50 examples run clean against the real registry, 6 deliberate error demos,
8 structural skeletons. 21 of 34 registered types now carry a block.