max / quasi

0.38.0: a terminal and an egui host can fill a bespoke region `d86122cf`, the media transport gap, ruled by Max 2026-08-18: bespoke fill, "bespoke for now, widgets eventually". MNW's media player is one island plus a thin scrubber and it stays where it is; B6 describes the page chrome around it and leaves the player alone. What the ruling assumed, and what was not true, is that a host could fill a bespoke region on any renderer. Only the webview could: `Webview::with_fill` took markup and the terminal said so in a comment where its counterpart should have been, while egui had neither the mechanism nor the note. Both have one now, each in its own currency, since decision 4's whole point is that a byte payload is not what egui or a terminal wants. `quasi_tui::Fill` is a trait with `rows` and `draw`: this renderer's contract is that a thing answers a height for a width and then paints into the rect it was given, and a fill that only drew would leave `Tui::height` reporting a region shorter than what is on the screen, so a pane would stop scrolling before the fill's last row. `quasi_immediate::Fill` is a closure over a `Ui` and no measure, because egui lays out in the order it is told and nothing asks a region how tall it is. The rules the webview already kept hold on all three: keyed by `Slot::id` rather than by the bespoke name, since a screen of N rows each carrying a fill shares one name and has N ids; drawn under the blocks the description owns, which is the arrangement `Containment::Opaque` describes; ignored when named against a pane, which is a host reaching into a region the description already owns; ignored when it names an id the screen does not have. `RegionKind::Bespoke` carries the ruling and its revisit trigger, which is the widget work rather than a count of consumers: a behaviour implemented once behind a fill and tested is a candidate to become a `Widget`, and the media player is the first of them.