TASK-069: a pushed screen's content is there as it stops

What loaded during a push was held 80 ms past it and then took a frame to
build, so the screen stood there still loading. It is now released 40 ms
before the push ends, where the screen has almost no way left to go.

Agent: main (opus)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

app/src/main/java/com/ubisam/ubgitea/ui/components/Motion.kt

@@ -492,16 +492,16 @@ fun <T : Any> PushedOver(
 const val ScreenPushMillis = 300
 
 /**
- * [value] as it stood when this screen began to push in, until it has arrived. What loads
- * meanwhile is shown once the screen stands still, so building it does not hold up the push.
+ * [value] as it stood when this screen began to push in, until it has all but arrived. What
+ * loads meanwhile is built in the push's last frames, where the screen moves a few pixels, so
+ * building it neither holds up the push nor leaves the screen standing there still loading.
  */
 @Composable
 fun <T> heldWhilePushedIn(value: T): T {
     val first = remember { value }
     var arrived by remember { mutableStateOf(false) }
     LaunchedEffect(Unit) {
-        // A little past the push: its first frame is the longest, and the push starts after it.
-        delay(ScreenPushMillis + 80L)
+        delay(ScreenPushMillis - 40L)
         arrived = true
     }
     return if (arrived) value else first

docs/development-log.md

@@ -1745,4 +1745,8 @@ This is the append-only implementation and handoff record shared by Codex and Cl
 - Checks and results: the five required checks pass.
 - Caution: the first frame of opening is not shorter; it delays the push's start and does not
   interrupt it.
+- Follow-up the same day: the product owner, on a release build, found the screen often still
+  loading after it had arrived. The state was held 80 ms past the push and then took a frame
+  to build. It is now released 40 ms before the push ends, where the screen has under 2% of
+  its way left, so the list is there as the screen stops.