iris-ai
581e07624f
Correcting by the error each pass could see, and asking again on the pass that answered, was a frame per pass with the ones in between drawn: opening a card visibly stepped. It also still missed, because two of the passes were spent finding out what the list would do rather than telling it. `requestScrollToItem` against the row itself says it outright, in one pass: the row is placed wherever it has ended up and whether or not it is still on screen, and a negative offset -- which is the list being asked for the rows below a card that has just given the screen its whole height back -- is exactly what a close needs and works. Everything else follows from where that puts it. A call opened or shut *inside* a group is a third case, and it was being treated as the second: the group is not the thing opening, it is the container, and centring it on the tap threw a group of six the length of the screen. What keeps the call under the finger is holding the group's top edge, so that everything above the change -- that call's own heading included -- stays where it is. Checked with ktfmtFormat, compileDebugKotlin, lintDebug and testDebugUnitTest, and on the emulator against the sandbox with sampling as fast as the device will report it, so an intermediate frame would show: a 2,785px card closed at 600, 1200 and 1800 lands centred on 600, 1200 and 1800 to the pixel, each in one step; opening by the heading holds the heading still; and opening or closing a call inside a group of five leaves the group's heading exactly where it was.