max / quasi

Draw a described screen in a terminal quasi-tui, the first non-webview renderer of the screen tree. Both hosts have always been webview hosts, so every finding that shaped this vocabulary came from a renderer that can express anything and therefore never pushed back. This is the consumer that pushes back. Drawing only. A screen in, cells in a ratatui buffer out, no state: flow layout, every node answering a height for a width and then drawing into the rect it was given. Focus order, scroll, field editing and history are the interaction runtime and are not here. Every `Node` member is drawn or declined in writing, and the declines are the point. What it found so far: - A secret field has no described value to draw. `Field::value` drops what it is handed when the kind is `Secret`, deliberately, and a browser owns an input's contents so a webview never noticed. This is the first node whose drawing is not a function of the description alone. - A tabbed list-detail does not say which tab is showing, and a tab has no label. `Slot::id` is an address chosen for fragment targeting, so using it as a heading puts `contacts-detail` on screen. - Nothing says a region's share of the width. The sidebar is 24 columns and the list pane 40% because this renderer picked those numbers. - `Node::Rich` loses its emphasis. The node carries source so each renderer can answer it its own way, and a terminal's own way should be bold rather than dropping it; docengine renders to markup or to text and to nothing in between. - A toast and a banner draw the same. A toast goes away on its own, which is a clock the description does not carry. - `quasi_http::Render` is an HTTP host's contract rather than a renderer's, so this implements nothing shared with quasi-webview. The row run is what made the list drawable without hardcoding a member order: the terminal reads the parts the description says, in the order it says them.