fix(ci): report why a PR could not be woken instead of guessing

[catomean]

Follow-up to #75.

The bug

The wake path decided whether a PR was conflicted by reading mergeable from the cached gh pr list payload. GitHub computes that field lazily and invalidates it every time the base branch moves — which is exactly when this workflow runs. The file already documents this trap for the merge path:

Mergeability is computed lazily by GitHub and is invalidated every time the base branch moves — so right after a merge (exactly when this workflow runs) every PR reports UNKNOWN.

The wake path did not honour it. A conflicted, check-less PR whose mergeable read UNKNOWN skipped the CONFLICTING branch, attempted update-branch, failed, and was told:

#N could not be woken (already current with main?) — close/reopen it to force checks

Close/reopen would not have helped — the branch conflicts. That is this file's own bug class: a skip line that reads plausible and sends the reader somewhere useless.

The fix

On failure, ask GitHub for the real mergeable state and name the actual reason:

• conflicting → "it conflicts with main — resolve the conflict (or @dependabot recreate)"
• otherwise → "it is already current with main — close/reopen it to force checks"

One extra API call, on a path that only runs when a wake has already failed.

Verification

• bash -n clean.
• The wake mechanism itself is proven live on this repo: deps: bump @playwright/test from 1.46.1 to 1.61.1 #37 and deps: bump lucide-react from 0.441.0 to 1.22.0 #39 were both check-less since June, both woken, both went green, both auto-merged (00:33Z and 00:45Z). deps: bump lucide-react from 0.441.0 to 1.22.0 #39 needed a real fix first — lucide v1 removed the Github icon.

🤖 Generated with Claude Code