ci: fail closed when e2e ref lookup is not a missing branch

[piotr-iohk]

Fixes two correctness gaps Phil (pwltr) found on the app twins that consume resolve-e2e-ref@main:

• bitkit-android#1318 — transport failures must not soft-fall back to main
• bitkit-ios#767 — same lookup bug
• bitkit-ios#767 — migration wallet setup reuses a stale ref on failed-job reruns

Please include ben-kaufman and pwltr as reviewers (same as the twin app PRs).

Transport errors are not a missing ref

git ls-remote --exit-code (git 2.43, checked locally):

Situation	Exit	stderr
Ref exists	0	empty
No matching ref	2	empty
DNS failure, missing repo, bad token	128	fatal: ... reason

resolve-e2e-ref used to send every nonzero status down the missing-branch path (>/dev/null 2>&1). A DNS or auth blip could therefore warn and check out main.

The action now:

• 0 — use the selected branch
• 2 — unchanged: soft-fallback to main for default-feature-branch / main, hard-fail for an explicit custom e2e_branch_input
• anything else — ::error and fail the step. stderr is kept in the log (not redirected away) and no ref output is written

The same distinction is in determine-e2e-branch.yml. That job runs first, and resolve-e2e-ref treats selected == main as already settled, so a transport error swallowed at determine time would still check out main for the rest of the run.

Migration wallet setup re-resolves before checkout

iOS prepare-wallets calls migration-wallet-setup.yml. On master it passes needs.e2e-branch.outputs.branch. ios#767 passes needs.resolve-e2e-ref.outputs.ref from a separate job. "Re-run failed jobs" does not re-run that successful resolve job, so a companion deleted after resolve is checked out again and fails again.

The reusable workflow now runs resolve-e2e-ref immediately before actions/checkout. Android migration already resolves in-job and does not call this workflow.

The action is referenced as synonymdev/bitkit-e2e-tests/.github/actions/resolve-e2e-ref@main. A relative uses inside a reusable workflow resolves against the caller (bitkit-ios), not this repo.

Input contract (backward compatible)

• e2e_branch (required, same name): candidate to re-validate. Callers can keep passing determine's output or a previously resolved ref.
• e2e_branch_input (optional, default default-feature-branch): same policy as the action. A missing companion warns and uses main. An explicit custom name hard-fails.

Callers that only pass e2e_branch (iOS master, and ios#767 as written) therefore soft-fall back when that candidate is gone. That fixes the stale-companion rerun without an app change. After this merges, iOS migration wallet setup on master will clone main with a warning instead of failing checkout when the determined companion has been deleted.

ios#767 should also pass the dispatch input so an explicit custom branch still hard-fails inside this job, and can pass determine's output directly (the separate resolve job is no longer what keeps the wallet checkout current):

with:
  e2e_branch: ${{ needs.e2e-branch.outputs.branch }}
  e2e_branch_input: ${{ github.event.inputs.e2e_branch || 'default-feature-branch' }}

Verification

Ran the bash from both YAML files with bash -eo pipefail (GitHub's default shell flags):

• exit 0 uses the branch
• exit 2 + default-feature-branch → main plus the existing warning
• exit 2 + custom name → Invalid e2e_branch, no ref output
• exit 128 and exit 1 → step fails, stderr in the log, no fallback (including when the input is a custom branch, so a transport error is not reported as a missing branch)
• empty selected, or selected already main → no ls-remote
• real git ls-remote against this repo for a missing ref (soft-fallback and custom hard-fail)
• real git ls-remote against a 404 repo → exit 128, Repository not found in the log, no fallback