docs(security): document temporary-fork CI and publication gates

[ss-o]

Problem

The security incident runbook recommends GitHub temporary private forks but does not document a material platform constraint: integrations cannot access those forks and status checks do not run on their pull requests.

That omission leaves the response procedure ambiguous when normal policy requires exact CI evidence, public documentation updates, or parent-workspace gitlinks. A maintainer can otherwise either disclose the remediation through a public branch too early or wait for CI that GitHub will never start.

Proposed update

• state the temporary-private-fork integration and status-check limitation
• require equivalent local validation evidence on the exact private head
• allow a separate public CI-only pull request only when its diff contains no vulnerability or remediation detail
• keep disclosure-bearing documentation and parent gitlinks unpublished until the private remediation is merged
• define the authority sequence for advisory merge, patched release when applicable, advisory publication, public documentation, and gitlink reconciliation
• record the unavailable-CI exception and exact local evidence in the draft advisory

Acceptance criteria

• runbooks/security-incident-response.md describes the full private-fork publication sequence without duplicating GitHub documentation
• the procedure preserves the existing rule against public exploit details
• merge, release, advisory publication, and unrelated repository publication remain separately authorized actions
• links point to GitHub's current temporary-private-fork documentation

Reference: https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability

[ss-o]

Publication evidence from GHSA-33c2-cgpq-8gpc:

• The temporary private-fork PR could not satisfy the public repository's required checks because integrations do not run in the temporary private fork.
• The advisory merge UI reported that the active main ruleset could block the merge, naming pull-request, status-check, linear-history, deletion, and force-push rules.
• Maintainer workaround: temporarily set only ruleset 21797700 to disabled, merge from the advisory UI, then immediately restore it to active after main advanced.
• Postcondition verified: all five effective rules are again present on main; the patched tag v1.67.1 resolves to the advisory merge commit.

This is concrete evidence for documenting a bounded advisory-publication bypass and restoration check.