fix: dependabot automerge with alternate identity

[chris11-taylor-nttd]

Uses the auto-approver identity as the merge source. This allows us to trigger actions off merge to main after a Dependabot PR merges, so that we're correctly tagging and releasing dependency updates.

Will become 0.15.1 and eventually 1.0.0 provided nothing else is found.

[bryce-lynn-nttd]

PR Review

Overall: Correct fix for a well-known GitHub Actions behavior — when GITHUB_TOKEN performs a merge, GitHub deliberately suppresses re-triggering of downstream workflows on the resulting push to prevent loops. That suppression is what's been preventing the release-on-merge workflow from firing for dependency updates. Performing the merge under a third-party app identity bypasses the suppression because the loop-prevention rule applies specifically to GITHUB_TOKEN-attributed writes. Standard, well-documented workaround.

The actions/create-github-app-token step is correctly SHA-pinned (1b10c78c…), consistent with the convention established in launch-terraform-skeleton#16. The if: github.actor == 'dependabot[bot]' gate is unchanged, so this only affects Dependabot PRs. Permissions block unchanged — the app token carries scopes via the installed app's permission set.

Non-blocking

1. The app naming carries skeleton-update semantics into a dependabot context. LAUNCH_SKELETON_UPDATE_APP_ID / LAUNCH_SKELETON_UPDATE_KEY are reused as the merge identity for Dependabot PRs, even though those PRs aren't skeleton-driven. Pragmatically fine — the same app has the right scopes — but the input name skeleton_update_app_id doesn't reflect the dual-use, and someone reading reusable-pr-dependabot-automerge.yml cold will wonder why dependabot needs a "skeleton update" app. Either rename the input to something generic like merge_actor_app_id (with LAUNCH_SKELETON_UPDATE_APP_ID as a sensible default), or accept that this app does multiple jobs and document it. Not worth blocking on.

Generated with Claude Code (Opus 4.7)