Fix StickyHeaderContainer header transitions (scroll-driven push) (#4851)

* StickyHeaderContainer: scroll-driven push transitions (#4849)

Replaces the time-based after-the-fact transition with scroll-driven
push behavior so the pinned header reacts in lockstep with the user's
finger:

- TRANSITION_SLIDE: as the next section's header rises into the slot
  it pushes the pinned header up by the overlap amount, replacing it
  seamlessly when the rising header reaches the top.
- TRANSITION_NONE: the pinned host is hidden during the overlap so
  the rising header (in the scroller) covers the slot naturally.
- TRANSITION_FADE: the pinned header's opacity drops from 255 to 0
  as the next section closes the gap, revealing it underneath.

Removes the time-based machinery (snapshot, animator, paintGlass
overlay) that caused the boundary jitter and the "B slides under A
then suddenly reappears below A" jump. transitionDurationMillis is
retained for API compatibility but no longer affects visuals.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Update sticky header golden screenshots from CI

iOS and Android emulator captures of StickyHeaderScreenshotTest,
StickyHeaderSlideTransitionScreenshotTest and (Android only)
StickyHeaderFadeTransitionScreenshotTest now reflect the new
scroll-driven push behavior.

The iOS Fade test PNG was not present in the artifact this run
(only the smaller preview chunks were emitted via the device log,
not the full-size PNG chunks) so its golden is left untouched and
will be refreshed once the next iOS run captures it cleanly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Update iOS sticky header fade golden from CI

The previous CI run dropped the full PNG chunks for this screenshot,
emitting only the preview, so it was skipped in the prior golden
update. The latest run captured the full PNG cleanly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Make Android decode-retry observable and more reliable

The previous retry path silently fell back to `monkey ... >/dev/null
2>&1 || true` whenever `cmd package resolve-activity --brief` returned
output that didn't fit the expected `pkg/.Activity` shape — which is
common on newer Android (the brief output sometimes prepends a
`priority=...` line and adds leading whitespace). When that happened
the retry waited the full 600s with zero diagnostic signal and
failed the build.

Replaces the resolve+monkey dance with `am start -W -a MAIN -c LAUNCHER
-p $PACKAGE_NAME`, which launches the app by intent filter and prints
a `Status=…` line we can parse. The output is logged verbatim, the
process is verified with `pidof` before committing to the 10-minute
wait, and the retry skips the wait entirely if no PID is detected so
CI fails fast instead of burning ten minutes on a no-op.

Also uploads `connectedAndroidTest*.log` as an artifact so the next
decode flake — if there is one — is reproducible from CI.

Comments in both files spell out the right mechanics and explicitly
warn against re-introducing output redirects, which were the root
cause of the silent failure.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Reinstall main APK before relaunch in Android decode-retry

The new diagnostics surfaced the actual root cause that was hidden
behind the previous silent-monkey fallback: Gradle's
connectedAndroidTest task uninstalls BOTH APKs at teardown
(`DeviceConnector ... uninstalling com.codenameone.examples.hellocodenameone`
appears in the gradle log next to the .test uninstall). By the time
the retry block ran, the package was gone and `am start` returned
"Activity not started, unable to resolve Intent ... pkg=...".

Fix: before relaunching, check `pm list packages` (with `grep -x` to
avoid `<pkg>.test` substring matches) and `adb install -r` the main
APK from `$GRADLE_PROJECT_DIR/app/build/outputs/apk/debug/app-debug.apk`
when it's missing. We don't need the .test APK — the main APK
contains Cn1ssDeviceRunner, which re-runs the entire suite when the
launcher activity starts.

Both branches of the install logic log their action and any failure
output so the next debugger can tell at a glance whether the install
succeeded, the APK was missing, or something further down (like
`am start`) is the real issue.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: shai-almog

.github/workflows/scripts-android.yml

@@ -189,6 +189,21 @@ jobs:
           if-no-files-found: warn
           retention-days: 14
           compression-level: 6
+      # Logcat captures from connectedAndroidTest and the in-script retry
+      # (`connectedAndroidTest.log`, `connectedAndroidTest-retry.log`). These
+      # are the only place to debug CN1SS chunk-decode flakes — they hold
+      # the raw base64 chunks plus the `am start` / pidof diagnostics. If
+      # this upload step disappears, the next decode flake will be
+      # un-debuggable: keep it.
+      - name: Upload Android instrumentation logs
+        if: always() && matrix.id == 'default'
+        uses: actions/upload-artifact@v4
+        with:
+          name: android-instrumentation-logs
+          path: artifacts/connectedAndroidTest*.log
+          if-no-files-found: warn
+          retention-days: 14
+          compression-level: 6
       - name: Upload Android test report
         if: always() && matrix.id == 'default'
         uses: actions/upload-artifact@v4