max / quasi

0.14.0: a renderer says how big a selection is, and will not commit an empty one Two things every bulk bar does and no description can say. The ticks on a screen are the host's until something submits them -- which is why `Act::over` gathers them at press time rather than the handler being told up front -- so a route answering from the store cannot know how many are set, and a commit control over an empty selection was offered, pressed, and answered "0 rows touched". A screen letting the reader find out by trying. Each renderer says both with what it already holds. The terminal and egui hold the set in their own `View`, so it is a count on the control's own label and a `State::Disabled` when the count is zero, plus a refused press and a refused key. The webview does not hold it -- the ticks are DOM state -- so this crate now ships `SELECTION_JS`, twenty lines reading two hooks the emitter already writes: `.row-select` on a tick and a new `data-over` on a control that commits one. `Shell::selection_src` says where a host serves it, `without_selection` drops it, and the fallback is safe rather than silent: a control stays enabled and says no count, which is what every screen did yesterday. That is the difference from `morph_src`, whose absence makes htmx swap destructively. The count rides on the control's label rather than in a status line, because a status line needs somewhere to go and nothing in the description says where. On the control it is unambiguous besides: it is the number this press would act on. Only a control that names a verb takes it -- a picker's words are a question, and a question with a count after it reads as one more option. Disabled rather than hidden. `bulk-actions.js` hides its bar and can afford to because its rows keep their checkboxes; a bar that vanishes takes with it the only evidence that bulk actions exist. `Act::over`'s doc gains the other half: a handler still answers for an empty set. A renderer's refusal is an affordance, not a guarantee about what arrives.