[Governance] Align external-head review policy with executable dispatch behavior

[seonghobae]

Problem

At protected-main baseline 6eb06cdd, policy prose says fork/external heads remain reviewable, while the targeted merge scheduler and the privileged OpenCode and Strix dispatch paths reject a head whose repository differs from the base repository. Operators and contributors therefore cannot tell whether external heads are supported, rejected by design, or waiting on a safe read-only path.

User and operational impact

• External contributors receive policy promises that the implementation cannot satisfy.
• Automation may classify the same PR differently depending on entrypoint.
• A future permissive change could accidentally mix untrusted fork source with privileged credentials.

Scope

Choose and implement one explicit contract:

1. safely review external heads as untrusted data without granting update/merge authority; or
2. reject them consistently and update product/governance policy with a supported maintainer-import path.

Do not broaden pull_request_target source execution or credential scope.

Acceptance criteria

• PRD/TRD/security/threat/UML describe one external-head contract.
• Scheduler, OpenCode, Strix, and mention dispatch apply the same classification.
• Exact source repository/ref/head and live base are revalidated at every dispatch boundary.
• External heads never receive branch-update, autofix, direct-merge, release, or deployment authority.
• Realistic tests cover fork, deleted/moved fork ref, same-name branch, private/inaccessible fork, and head movement.
• The protected-main path is exercised against a real external-head fixture before closure.

Dependencies

Coordinate snapshot identity with #840.