auto-merge-dependabot.yml: merge silently fails when PR is still "unstable", never retries

[aquarion]

Summary

The auto-merge-dependabot.yml reusable workflow reports success (green check) even when it fails to actually merge or enable auto-merge on the PR. Consumers see a passing "automerge" run but the PR is left open indefinitely.

Observed in istic/wereabouts PR #302.

Root cause

1. The "Wait for checks to complete" step never actually waits. It runs:

   gh pr checks "${PR}" --watch --interval 30 || true
   

   but the job never checks out the repository first, so gh pr checks fails immediately:

   failed to run git: fatal: not a git repository (or any of the parent directories): .git
   

   The || true swallows this, and the step logs "Checks have settled, proceeding with merge" after essentially 0 seconds — the intended 15-minute wait never happens.

2. The merge is then attempted while the PR is still UNSTABLE. Because checks haven't finished, fastify/github-action-merge-dependabot@v3's merge/enable-auto-merge call is rejected by the GitHub API:

   ##[error]Request failed due to following response errors:
    - Pull request Pull request is in unstable status
   

3. That failure doesn't fail the job. The composite action swallows the API error, so the outer step and the whole workflow run report conclusion: success — masking the fact that nothing was merged.

4. Nothing retries it. The workflow only triggers on pull_request (default types: opened, synchronize, reopened). Once the single attempt fails, there's no listener for check-suite/status completion, so the PR is left green/mergeable but never merged until some unrelated event (new push, manual merge, ·@·d·ependabot r·ebase) touches it again.

Suggested fix

• Add an actions/checkout step before gh pr checks so the wait step can actually run (or drop the manual wait entirely and rely on GitHub's native use-github-auto-merge: true, which already waits for required checks once enabled).
• Don't attempt the merge/approve call while the PR is still in an unstable/pending state — either retry with backoff, or make the workflow also trigger on check_suite/status/workflow_run completion so a later success re-triggers the merge attempt.
• Consider failing the job (or at least emitting a warning annotation) when the merge/enable-auto-merge call errors, instead of swallowing it, so a real success vs. silent no-op is visible from the Actions UI.