max / quasi

Chrome carries the places the app has, and says what each panel is for `71aa29b4`, ruled (e) by Max 2026-08-22. One panel was enough while the only measured consumer was goingson's timer band. It stopped being enough the moment an app wanted a tab bar as well: goingson's shell is three tabs, a sub-nav under the chosen one, a sync indicator and the band, and `presenting` replaced rather than appended precisely because a renderer handed two anonymous panels would place them by declaration order. Two members rather than a longer list of one kind. `Chrome::nav` holds `Place`s: a key, a label, an address, and one level of places within. A tab bar is not content that happens to be always on screen, it is a set of addresses with names, and saying so is what lets a webview draw tabs, a terminal draw a tab line and an egui host draw a toolbar without any of them being told which. There is no `Role::Navigation` for the same reason. `Chrome::panels` is plural and each carries a `Role`. `Activity` is something the app is doing right now, on screen while it lasts; `Status` is a standing readout of its condition. goingson's two are one of each. The role says what a panel is for and still not where it goes, which is the line `46fc763c` and `4453bf82` drew. WHICH PLACE IS CURRENT IS THE SCREEN'S TO SAY, and this is the part the ruling did not settle. Chrome is built once and held beside the router, so a `current` flag on a Place would be frozen at build time and could never point at where the user is. `Screen::place` names the key instead and the renderer marks the Place that holds it, which is exactly the move `Row::current` makes one level down. The alternative was the renderer matching a place's address against the request path, which needs the path in `Serves::screen` and goes fuzzy the first time a screen carries its view on the address; goingson's Timer is `/timer?work=25&days=7` and its place is `/timer`. THE THREE RENDERERS, each answering placement its own way, which is the whole point of the description not answering it. quasi-webview emits a `nav` of links (middle-click, status bar, landmark: none of which a button gets) with `aria-current="page"` on the current place, and `data-role` beside the `chrome-panel` class rather than instead of it, so a stylesheet written when there was one panel still finds it. quasi-tui draws a tab line across the top, two rows when the current place holds others, reverse video for current, and stacks panels activity-above-status so the app's condition sits where a status line goes. quasi-immediate draws them in the same order down its column. A terminal's places are reachable: `reaches_chromed` walks the nav first because it is drawn first, and only the row actually on screen. A tab line the user can read and cannot use would be worse than none. An app declaring no nav and no panels gets what it always got, in all three. 0.53.0, breaking. Consumers forward-fixed in the same pass: goingson declares its band `Role::Activity`, and goingson, audiofiles and the MNW server all move their requirement. The MNW server is the one the `Chrome` grep missed and the pre-push gate caught.