max / quasi

0.40.0: a toast goes away on its own, and each renderer holds the deadline `4453bf82`, the notice half of the ruling on `f00244a6` (Max, 2026-08-18): the renderer owns the expiry, and `Notice::Toast` is not advisory. The filed task read as though the description said nothing about a toast's lifetime. It says the thing that matters -- `Notice::transient()` is already there and already routes a toast to `Fill::Overlay` -- and only the when was missing, which is presentation policy of the same class as how long an undo stays offered. So no vocabulary member was added. What was missing is that all three renderers drew a self-dismissing message and then never dismissed it. Each renderer names the duration once, as `LINGER`, and the three carry the same four seconds for the reason the clock spellings match: a screen described once and drawn three times should not keep its messages for three different lengths of time. A banner is never on a clock, and goes when the condition it reports is fixed. quasi-tui and quasi-immediate hold an instant per toast beside the screen and answer `Runtime::expires`, which takes away the ones whose time is up and says whether one went. The bookkeeping is positional, because a notice has no identity to key on: a toast joins the screen at the end of the list or arrives inside a whole screen, and a screen arriving, or coming back out from under an overlay, starts every toast on it lingering from then. `Runtime::tick_in` now answers what is left of the nearest toast's linger as well as the finest cadence the screen's readouts demand, so a terminal blocking on a key wakes to take the message off, and `tick_in_at`/`expires_at` are the seam a caller holding a clock uses. quasi-immediate calls `expires` itself once a frame and asks the context for the frame that finds the deadline, so an app drawing that runtime gets it without doing anything. quasi-webview emits `data-notice="toast"` beside the class -- an attribute for `data-clock`'s reason, since a class carries the host's prefix and a script shipped by this crate cannot know it -- and `CLOCK_JS` takes the element off the page when its time is up. It rides in the clock script rather than in a second script the host has to serve, because it is the same fact: what a browser knows about the time and a description cannot. A timer per toast there, which is what the readouts deliberately avoid; the reasoning comes out the other way because a page carries one or two toasts whose timer runs once. Consumers forward-fixed to 0.40: MNW server, audiofiles, goingson. The scaffolder's template was pinning 0.30 and is current again.