chore: fix tests

chore: update ios test timeout

chore: inrease maestro driver setup timeout

chore: address flaky tests

chore: fix tests

chore: revert

chore: revert

…mits

The Android IntroScreen flow failed at its last assertion: after re-entering
the page, NEXT moved slide 2 -> 3 and the attribute correctly became 3, then
immediately flipped to 1, so "Active slide: 3" was never visible. The failure
video shows the value on screen going 2 -> 3 -> 1 with no input in between.

Cause: once the programmatic scroll to slide 3 settles, Android's list emits a
SECOND onScrollBeginDrag + onMomentumScrollEnd pair, and that momentum event
carries the offset the list moved AWAY from (0). The existing pendingScrollTarget
guard had already been cleared by the first, legitimate momentum end, and
wasUserDragging was true because the settling list — not a finger — began the
drag. So the event was treated as a swipe back to slide 1 and rewrote the
attribute. This is the same class of bug as the earlier phantom-momentum fix,
one step later in the sequence.

Fix: remember the slide a programmatic scroll settled on, and ignore a momentum
end that moves more than one page from activeIndex while that memory is set.
The list is pagingEnabled, so a genuine drag moves exactly one page; a
multi-page jump right after a scroll settled can only be that scroll's tail.
One-page swipes, including a swipe straight after a programmatic scroll, still
report normally (covered by existing tests).

Regression test added; it fails with setValue receiving [3, 1] and a spurious
onSlideChange(0, 2) when the guard is removed.

Revert "fix(e2e): scroll the alphabet-index target into view before tapping it"

This reverts commit 31e9fd78c2fb70fb0e88b33b2d9bf8a983c4db51.

fix(e2e): scroll the alphabet-index target into view before tapping it

FloatingActionButton.yaml failed on iOS with

  Tap on "F"... COMPLETED
  Assert that "Floating action button" is visible... FAILED

then passed on retry with the same build. The flow already had the 10s
extendedWaitUntil added in 20d3d52, and that wait is what timed out — so
this is not the render race that commit fixed; nothing was going to change in
second 11 and a longer timeout would not have helped.

extendedWaitUntil: visible requires the element to be IN THE VIEWPORT, not
merely present in the hierarchy. Tapping the index scrolls to the letter's
section, and under F the entries are Feedback then Floating action button; if
the scroll settles with Feedback at the bottom edge, the target is rendered
just below the fold and `visible` stays false forever. The retry's scroll
landed a few pixels differently and it passed.

Use scrollUntilVisible instead: it succeeds immediately when the element is
already in view and scrolls to it when it is not, so it covers both the
original render race and the off-screen case. centerElement keeps the
subsequent tap away from the screen edge.

Applied to the 55 flows whose index letter hosts more than one widget entry
(B, C, F, I, L, P, R, S) — the case where the target can be pushed below the
fold. The 16 flows on a sole-entry letter keep the cheaper wait.

Verified: all 82 flows still parse, all 71 index taps remain guarded (55
scrollUntilVisible + 16 extendedWaitUntil, 0 unguarded), and the pinned 2.6.1
binary accepts every field used — confirmed it rejects an unknown property, so
that parse is a real schema check.

ci(e2e): archive maestro's debug output for failed flows

Maestro writes a debug bundle per run — failure screenshot, maestro.log
(which records the element Bounds each selector matched) and
commands-<flow>.json — to ~/.maestro/tests/<timestamp>/. That is outside the
workspace, so none of it was ever uploaded, and it is exactly what
distinguishes "element never rendered" from "element rendered off-screen
below the fold" when an assertVisible/extendedWaitUntil fails. Without it
those failures can only be diagnosed by inference.

Redirect it into the workspace with --debug-output (+ --flatten-debug-output,
which its own help text recommends for CI) one dir per flow, and archive it.
Kept only for FAILED flows, mirroring the existing video policy, so a green
shard uploads nothing — each bundle is ~300KB.

Also gitignore maestro/debug and maestro/videos: both are produced into the
workspace by local runs too. The existing *.log rule covered maestro.log but
not the bundle's screenshots or commands JSON.

Verified --debug-output and --flatten-debug-output against the pinned 2.6.1
binary, and drove run_tests with a stub to confirm a failing flow's bundle is
kept while a passing flow's is discarded.

fix(maestro): recover from iOS driver/accessibility faults instead of hanging

A shard could die with, and never recover from:

  Exception in thread "main" UnknownFailure(errorResponse=Request for
  viewHierarchy failed, code: 500, body: {"errorMessage":"Error getting
  element frame kAXErrorInvalidUIElement","code":"internal"})

Traced through the pinned 2.6.1 jars, this is unrecoverable by design.
XCTestDriverClient.handleExceptions maps a 500 to a typed error only for
four known message strings and otherwise throws UnknownFailure;
XCTestIOSDevice.execute catches only AppCrash/OperationTimeout/Unreachable,
and IOSDriver.runDeviceCall catches only the matching IOSDeviceErrors.
UnknownFailure matches none, so it escapes to main — hence "Exception in
thread main" rather than a failed step, and hence a flow-level `retry:`
block cannot help: the CLI is already dead, no command failed. kAXError*
means the accessibility element reference is stale, so every later query
against that driver fails identically.

Recovery therefore has to live in the shell. Add run_maestro(), which:

  - runs `maestro test` under a wall-clock watchdog (MAESTRO_FLOW_TIMEOUT,
    480s) so a JVM that died in main but is held open by non-daemon threads
    can't eat the 30-minute job budget, and
  - classifies a FAILED run as infrastructure (exit 90) when the output
    carries a driver/accessibility signature, so callers can tell "the
    device broke" from "the widget is wrong".

run_tests then resets the device and gives the flow one clean attempt with
a freshly reinstalled driver, instead of recording a widget failure and
marching every remaining flow through the same wedged driver. All three
call sites (flows, smoke check, retries) now go through run_maestro, and
the duplicated device-reset branches collapse into reset_device().

Only non-zero exits are reclassified, so a flow that passed after Maestro's
own internal retry logged such an error still counts as a pass.

fix(maestro): actually apply the iOS driver startup timeout

MAESTRO_DRIVER_STARTUP_TIMEOUT was passed to maestro as `--env`, but
LocalXCTestInstaller.getStartupTimeout() reads it with System.getenv() —
`--env` only fills Maestro's per-flow variable map, which that function
never consults. So every value we passed was silently ignored and the
Kotlin runCatching kept falling back to its built-in 120000 default.
Export it instead (and raise it to 240000), and drop the three no-op
`--env MAESTRO_DRIVER_STARTUP_TIMEOUT` arguments.

Also stop reinstalling the XCUITest driver once per flow. Maestro's
TestCommand.reinstallDriver defaults to true, so each `maestro test`
process runs restartXCTestRunner (uninstall + install + start) — and that
install is the window that throws IOSDriverTimeoutException on a 3-vCPU
macOS runner. The smoke check still installs the driver fresh at the start
of every shard and retries still reinstall via restart_simulator, so only
the first-pass flows reuse it. MAESTRO_REUSE_DRIVER=false restores the
old behaviour.

The ios-app job paid npm i + pod install + xcodebuild on every run, even for a
widget-only change that cannot affect the native app. That is the most expensive
step in the pipeline and it runs on a scarce macOS runner.

It is safe to skip because the Mendix JS bundle is a RESOURCE of the .app rather
than compiled input: in nativeTemplate.xcodeproj the `Bundle` entry is a folder
reference (lastKnownFileType = folder) in the Resources phase, there is no
react-native-xcode.sh phase (unlike a stock RN app the template never builds a
bundle itself, it only copies what mxbuild produced), and AppDelegate resolves it
at launch through MendixAppDelegate.getJSBundleFile(). Widget .mpks are compiled
into the JS bundle by mxbuild, never into the iOS binary. So on a hit we restore
the previous .app, replace its bundle folder, and skip the build entirely; the
job's uploaded artifact is unchanged, so prepare_ios.sh and the test shards are
untouched.

Two fixes to the caching this replaces, which cached DerivedData but still built
every time:

- The old key hashed ios/**/*.swift and Podfile.lock but not
  native_dependencies.json. add-native-dependencies.js merges that file into
  native-template/package.json and the Podfile autolinks from there, so
  `pod install` REGENERATES Podfile.lock — the committed lock is not the
  effective one and a new native dependency did not change the key.
- restore-keys: ${{ runner.os }}-ios-build- restored the newest entry whatever
  changed, mixing stale products with fresh pods. A partial-input change must
  rebuild, so the new key has no restore-keys.

The key also pins the resolved native-template commit (nt_branch can be a moving
branch, so the name is not a content identity) and the Xcode version, since the
runner image updates it independently of our inputs. A hit that does not contain
the exact .app prepare_ios.sh installs, with a bundle inside it, warns and falls
back to a full build rather than shipping a half-swapped app.

Caches only the Products dir, not the DerivedData root: it is what we upload and
a fraction of the size, so it does not evict the AVD/dist caches.