ci(dependabot): approve and merge updates via github-sts

[sds]

Motivation

We are disabling the org-level "Allow GitHub Actions to create and approve pull requests" setting, after which the built-in GITHUB_TOKEN can no longer open or approve pull requests. This is the only workflow in the org that approves PRs with github.token (gh pr review --approve + gh pr merge on Dependabot patch/minor updates).

Changes

• Mint a short-lived GitHub App token via STS (tempoxyz/gh-actions/actions/github-sts, SHA-pinned) and use it for the approve and merge steps. The check-watching step keeps the read-only built-in token.
• Drop the workflow's built-in token to read scopes and add id-token: write.
• Add .github/sts/dependabot.sts.yaml. pull_request runs carry the bare repo:...:pull_request OIDC subject, which any PR-triggered workflow in the repo can present, so the policy narrows with claim checks: actor/actor_id must be dependabot[bot] (a human pushing to the PR branch becomes the actor and is denied) and job_workflow_ref must be this workflow.

Things to verify before relying on this

1. Dependabot-triggered runs and OIDC. Dependabot-actor pull_request runs are permission-restricted like fork PRs; the permissions: block lifts scopes, but please confirm a Dependabot PR can actually obtain an OIDC token (id-token: write) before flipping the org setting. If it cannot, the fallback is moving this workflow to pull_request_target pinned to the base ref.
2. Verified-human review requirements. The org recently moved toward requiring verified-human reviews. The STS App's approval will post fine, but on any repo whose ruleset requires human reviews it will not satisfy the requirement — worth confirming what this auto-approve is meant to satisfy on mpp-tools and the callers below.

Downstream callers need follow-ups

This workflow is also consumed via workflow_call (pinned by SHA) from mpp, mpp-rs, mpp-go, mpp-specs, pympp, hermes-mpp, and one private repo — at runtime the approve/merge there uses each caller's own token, so those repos break identically when the org setting flips. After this merges, each caller needs a follow-up PR that:

1. bumps the pin to the new SHA,
2. grants checks: read, contents: read, pull-requests: read, id-token: write on the calling job, and
3. adds its own .github/sts/dependabot.sts.yaml (the STS action scopes to the repository the workflow runs against, so the policy lives in the caller).