max / quasi

0.13.0: a table row can join a selection, and a picker can act on one `Screen::selecting`, `Row::ticking` and `Act::over` have had no consumer outside this workspace's own tests since they were built. goingson's task list is the first, and it wanted two things that were not there. `Cells::ticking`, mirroring `Row::ticking`. The member was held back on the stated grounds that no table asked for one and a member added because its sibling has it is a member with no consumer to tell us what it should mean. The consumer says: the tick is the row's and the set is the screen's, exactly as on a list; it takes no column, because it does not narrow, sort or carry data; and a filter change does not preserve it, which is not a gap -- a filter is an address and the answer is a new list, so the ticks go because the rows do. The webview draws it in a gutter cell with a matching cell in the head, since `display: table` aligns by position; the terminal and egui add a leading column, Essential so narrowing cannot take the affordance away. `Field::over`, because a bulk bar is not only buttons. Of the five controls over goingson's task selection, two are acts and three apply a value to the set: set the project, set the priority, snooze until. Said with acts alone a project picker over forty projects is forty buttons in a bar. `Fires::include` came out of that. A field group already gathered its own control by selector and a control over a selection gathers the ticks by another, and both wrote `hx-include` -- two of them on one element, which is markup a parser drops half of. The selectors are joined in one place now. A table row is also reachable in the terminal when it is tickable rather than only when something opens it. A row drawing a box nobody can reach is the dead affordance `5f2b8753` was filed for, one node over.