max / quasi

0.35.0: a mount puts a frame around a screen `1adcb5f2`. A third top-level member, and each of the three answers a different question: Screen { .. } what the screen is Shell { .. } what only the host knows Frame { verbs, status } the frame a mount puts around a screen Supplied where a screen goes up rather than arriving with one. That is the whole of it: goingson's compose is the same fields, the same behaviours and the same builder in both its windows, and everything that diverges between them is the wrapping. The screen cannot say whether the verb beside it reads Cancel or Discard, because that depends on where it was put up. Not `Chrome`, which is the app's and outlives every screen; not on `Screen`, which would carry fields meaning nothing in half their uses. Of the five measured divergences the vocabulary keeps one: which verbs a mount supplies. Where they sit is the renderer's, and reproducing goingson's footer-here toolbar-there split would be describing the accident instead of answering it. `status` says the mount has a place to say what happened, and nothing more. `Frame::holds` is the rule -- a banner rests there, a toast floats regardless -- so the messages keep arriving as `Screen::notices` and the vocabulary grows no second way to say one thing. The channel question the ruling flagged is still open and still worth its own task. All three renderers honour it. The webview emits it outside `<main>` beside the chrome, for the chrome's reason one lifetime along: a fragment replaces what is inside, and a frame outlives every answer that lands in it. The terminal takes its rows off the bottom before the screen is drawn, and walks the verbs in one `Pass` with the screen so the focus count cannot restart and light the wrong control. egui draws it last, which is what "under the screen" means to a host that lays out in the order it is told.