Report build status via the GitHub Checks API using the halide-ci App

[alexreinking]

Summary

• GitHubStatusPush only posts to the legacy Statuses API, which has no "in progress" state — a running build shows a static pending dot instead of GitHub's spinner. The Checks API has that state, but requires GitHub App auth (a PAT can't create/update check runs).
• Adds GitHubAppCheckPush (subclasses GitHubStatusPush, overriding only _get_auth_header and createStatus to hit check-runs instead of statuses) and AppInstallationToken, a buildbot IRenderable that mints and caches installation access tokens from the halide-ci App, so it plugs into the existing token= argument unchanged.
• Wires the new reporter into master.cfg using the halide-ci App's client ID and installation ID, backed by a new secrets/github_app_private_key.pem (mounted via docker-compose.yml, ignored via .gitignore). The existing GITHUB_TOKEN PAT is untouched — it's still used by the webhook handler.
• Adds the new module to the same ruff/bandit/vulture/ty coverage lists custom_steps.py already has.

Test plan

• pre-commit run --files master/github_app_check_push.py master/master.cfg docker-compose.yml pyproject.toml .pre-commit-config.yaml .gitignore — all hooks pass
• buildbot checkconfig on master/master.cfg passes (verified with stubbed secret files for keys not present in this checkout)
• Manually drove AppInstallationToken.getRenderingFor under a real Twisted reactor with _fetch mocked: single-caller caching works, and 3 concurrent renders against an expired token collapse to exactly 1 underlying fetch (the DeferredLock guard works as intended)
• Deploy and confirm a real PR build shows the GitHub Checks spinner instead of a pending dot, and that the App's Checks permission is granted for the Halide/Halide repo specifically (not just the org)