fix(ci): increase apt retry timeout to prevent kill EPERM crash

Restore timeout_minutes from 3 to 5 for the apt-get retry step, and
add retry_on: error to only retry on command failure, not timeout.

The 3-minute timeout was too tight: DPkg::Lock::Timeout=120 means
apt-get can legitimately take up to 120s waiting for the dpkg lock
on each of the two sudo calls (update + install). With slow mirrors
on top, total time can approach or exceed 180s, triggering the
nick-fields/retry timeout. When the timeout fires, the action tries
to process.kill() the sudo child process, but since sudo runs as
root and the runner runs as admin, Node.js gets EPERM — a known
upstream bug (nick-fields/retry#124). The action crashes instead of
retrying.

With timeout_minutes: 5 (300s), even worst-case lock wait (240s) +
slow install (30s) = 270s fits with 30s headroom. apt-get resolves
on its own before the timeout fires, so the kill path is never hit.

Adding retry_on: error ensures retries only happen on actual apt
failures (mirror desync, lock timeout), not on the retry-action's
own timeout — which would crash with EPERM anyway.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: alucardzom

.github/actions/setup-e2e-env/action.yml

@@ -116,9 +116,10 @@ runs:
       if: ${{ inputs.platform == 'android' && inputs.setup-simulator == 'true' && runner.os == 'Linux' }}
       uses: nick-fields/retry@ce71cc2ab81d554ebbe88c79ab5975992d79ba08 #v3.0.2
       with:
-        timeout_minutes: 3
+        timeout_minutes: 5
         max_attempts: 3
         retry_wait_seconds: 30
+        retry_on: error
         on_retry_command: sudo apt-get clean
         command: |
           set -euo pipefail