ci: auto-PR upstream XMRig pin bumps — detect, build-verify, open an easy-merge PR #225

Why

The XMRig pin (XMRIG_VERSION + commit-verified XMRIG_COMMIT) is the one dependency nothing watches: Dependabot covers the SHA-pinned actions, but an upstream XMRig release sits unnoticed until a human remembers to check. For the fleet that means missed perf/fixes; for the repo it means the pin rots. The posture stays the same as everywhere else (#18, #148): we tell you an update exists via a reviewable PR — we never fetch-and-run.

Scope

• Weekly scheduled workflow (+ workflow_dispatch): query XMRig's latest release, compare against the pinned version, exit quietly when current.
• On a new version: resolve the tag to its commit (git ls-remote ... 'refs/tags/<tag>^{}'), build-verify — clone at that exact commit, assert the SHA matches, full cmake build on the runner, assert the binary exists (build only, nothing runs) — then update the two pins in rigforge.sh, append a [Unreleased] changelog bullet, and open a PR with the upstream release notes linked.
• Required checks must actually run on the bot PR: GITHUB_TOKEN-created PRs don't trigger on: pull_request workflows, so the bump job dispatches ci.yml + security.yml on the branch head (both gain workflow_dispatch:); the check runs land on the head SHA and satisfy the branch protection.
• Injection hygiene: the upstream tag is third-party input — validated against ^v[0-9]+(\.[0-9]+)*$ and passed via env, never templated into run: (keeps zizmor green).
• Docs: SECURITY.md supply-chain section gains one sentence; CONTRIBUTING notes the PRs are bot-opened, human-merged.

Acceptance criteria

• With the pin current, the scheduled run is a quiet no-op.
• With upstream ahead: a PR appears with the version + commit updated in rigforge.sh, a changelog bullet, the build-verify log green, and all required checks running.
• A malformed/hostile tag name fails the run without touching the repo.
• zizmor + yamllint green; make test unaffected.