Open a call from its foot upward, as a row already does

A closed call inside a group opened downward wherever it was pressed: the
anchor asked for the group's top in every case, which is right for a tap on the
call's heading and wrong for one at its foot, where what the reader wants held
is the edge under their finger. It is the rule every other row has had since
the anchoring went in, applied one level down.

An open in the call's lower half now asks for no scroll at all, which is the
same answer a row gets and for the same reason: the list holds the group's
bottom edge, a Column keeps the calls below the one growing at their distance
from it, so the growth comes off the call's top. The closing behaviour is
untouched -- the arithmetic is the same shift, written as the one term it
cancels down to, since where the call sits in the group and where the group
sits in the viewport drop out of it.

Checked with ktfmtFormat, compileDebugKotlin, lintDebug and testDebugUnitTest,
and on the emulator against a sandbox group of six calls, with enough
conversation behind it for the list to actually scroll -- a transcript shorter
than the viewport pins to the bottom and gives every anchor the same answer,
which is how this was missed. A call closed at 1321..1447: opened from 1430 it
leaves the call below it at 1485 to the pixel and takes the growth off its top;
opened from 1360 it leaves the calls above it where they are and moves the one
below down by the full 327; closed again from 1400 it lands at 1338..1464,
centred on the tap within a pixel.

PLAN.md

@@ -1210,7 +1210,12 @@ dev-updater (Kotlin 2.4.x, CMP 1.11.x, JDK 21).
      call is drawn and how tall that card is (`onToolToggle`), which is the
      part only it knows, and the calls above the one toggled do not move, so
      shifting the group by the difference puts the call where the finger
-     wants it.
+     wants it. A call opened in its lower half asks for nothing at all, which
+     is the same answer a row gets: the list holds the group's bottom edge, a
+     Column holds the calls below the one growing at their distance from it,
+     and so the growth comes off the call's top. Asking for the group's top
+     in every case — which it did for a day — was an open pressed at the
+     card's foot driving it downward instead.
      **The scroll is asked for in the gesture, not from the layout that
      discovers the new height**, and that is what makes it invisible: a
      request made at the tap is consumed by the same measure pass that first