docs(admin): overhaul the GitHub App integration guide with the provisioned permission model

[FelixTJDietrich]

docs/admin/github-integration.mdx now drifts from the live, deliberately-designed app configuration (both hephaestus-aet and hephaestus-staging-aet were rebuilt 2026-09-01 to a tiered model and are byte-identical). The guide is also the operator's template for self-hosted installs, so it must teach the model, not just list checkboxes. Fold in the following session knowledge:

1. Tiered permission model (replaces the flat tables):

• Core contract (required to function): Metadata R, Contents R, Pull requests RW, Issues RW, Discussions R, Members R, Organization projects R — with the "why" per row as today.
• Provisioned tier (reads granted ahead of features to avoid re-approval rounds; each names its roadmap issue): Checks R, Statuses R, Actions R (feat(integration): ingest CI signals (checks, pipelines) and expose them to practice detection #1403, feat(server): snapshot head-commit CI status at merge for the practice detector #1338), Deployments R (feat(integration): ingest deployment and release signals for delivery practices #1676), Merge queues R (feat(integration): ingest merge-queue and branch-lifecycle signals #1677), Dependabot/Secret-scanning/Code-scanning alerts R (feat(integration): ingest security-alert signals for vulnerability-response practices #1675).
• Held tier (documented non-grants with triggers): Checks write ships only with annotation delivery (feat(integration): deliver practice feedback as check-run annotations #1678); Administration read held until GitHub offers a narrower branch-protection grant; Copilot metrics gated on the privacy assessment (feat(integration): AI-adoption signals via Copilot metrics #1679).

2. Event list update: the full current set incl. the provisioned families (check_run, check_suite, status, workflow_run, workflow_job, deployment, deployment_status, deployment_review, merge_group, merge_queue_entry, release, commit_comment, create, delete, dependabot_alert, secret_scanning_alert, code_scanning_alert, issue_dependencies) with one-line rationale each, and an explicit "deliberately not subscribed" list (deploy_key, team_add, deployment_protection_rule, exemption_request_push_ruleset — approval-gate/plumbing events; the app observes, it never gates).

3. Operational mechanics section (currently undocumented):

• Permission increases take effect per-installation only after each installed org approves the pending request (org → Settings → GitHub Apps); reductions and event changes apply immediately. Batch increases to minimize approval rounds.
• Brand vs instance URLs: homepage = product domain (hephaestus.build); webhook URL + OAuth callbacks = the instance hostname — webhook deliveries do NOT follow redirects, so a brand-domain webhook URL silently loses every event.
• Failed-delivery triage and Redeliver live on the App's Advanced tab.
• App ownership transfer (e.g. to an org) preserves app ID, client credentials, private keys, and all installations; after transfer check "Where can this app be installed" → Any account.
• Consent-screen texts: description mirrors the literal grants (reads vs writes, "never modifies your code"), per-environment apps required (single webhook URL per app), staging apps carry a name suffix.

Done when the guide teaches the tiered model with per-row rationale, the operational-mechanics section exists, the manifest/OAuth templates match, and a note instructs future permission changes to update this page in the same PR (no app/docs drift).