Audit publication: diagnose hosted INTERNAL_ERROR at the API boundary

[jeffhuber]

Follow-up to #1023, #1025 and #1028. This is reliability work and does not block the owner-approved basic Slack v1.5.0 boundary.

Problem

The default-branch publisher now validates workflow identity correctly and emits bounded refusal diagnostics, but replaying already sealed PR #1024 metadata still fails before writing a reservation with INTERNAL_ERROR in run 35310148981. A read-only local replay of all API-side validation using the same metadata succeeds. This indicates an unexpected exception specific to the GitHub-hosted token/API/runtime path, not a Refused trust-check result.

Scope

• Wrap GitHub API/runtime boundaries with fixed, non-sensitive stage/status codes so HTTP failures, response-shape failures and missing fields identify the operation without exposing response bodies, paths, tokens, identities or submitted metadata.
• Reproduce with the existing sealed Slack: explicit private-workspace setup, readiness doctor and runbook #1024 source run 35308536301, attempt 1, head 942f1b37d7e1d3f1b404af792e7c41e3ace361f2; do not rerun a model merely to diagnose publication.
• Correct the exact permission/response/runtime mismatch while preserving workflow name/path/event/default-ref/run-attempt/SHA checks, source seal, exact PR head, replay ledger, reservation, receipt and cleanup.
• Prove an end-to-end bot-authored attested PASS and authoritative gate on a fresh exact-head audit after the fix.

Acceptance

• Unexpected HTTP/response/runtime failures emit only fixed safe operation/status codes.
• The sealed replay either publishes successfully or identifies one precise safe stage code.
• A fresh PR demonstrates default-branch publication, receipt, label transition and gate without owner override.
• Adversarial privacy and forge-resistance tests remain green.

No Slack canary, provider session, deployment or package publication belongs to this issue.