Research and design GitHub-native review enforcement

## Type

Research

## Area

GitHub Integration

## Priority

P2 — Medium

## Problem

It is unclear how a review decision could participate in GitHub merge controls without conflating review generation with enforcement. The verdict→status mapping and SHA-binding/stale-review behavior questions are now answered by the shipped `skills/github-pr-review/policies/review-status-enforcement.md` (via #34/PR #112 — see #92, #94, closed). The mechanism choice (Commit Status API vs Checks API) and the rulesets-vs-branch-protection comparison were never actually researched, and no consolidated recommendation document exists.

## Goal

The remaining genuine research gaps — mechanism choice and ruleset/branch-protection comparison — are answered and consolidated into one short recommendation that #34 can point to as its design basis.

## Scope

Child issues:

- [ ] #91 — Mechanism choice (Commit Status vs Checks API) + permission requirements
- [x] #92 — Review decision → status mapping (closed, answered by `review-status-enforcement.md`)
- [ ] #93 — Rulesets vs classic branch-protection comparison
- [x] #94 — Failure and stale-review behavior (closed, answered by `review-status-enforcement.md`)
- [ ] #95 — Consolidated recommendation note

## Non-Goals

- No further implementation in this initiative — #34 already shipped the behavioral spec.
- No auto-merge and no ruleset or branch-protection mutation.

## Note on process

#34's body was edited shortly before it merged to retroactively claim #91–#95 as its
design basis, but none of those issues were ever touched or linked to an artifact.
The substance mostly turned out fine (#92/#94's questions are in fact answered by
the shipped policy), but future dependency claims in this repository should be
verified against a real linked artifact before a PR merges, not asserted after the fact.

## Acceptance Criteria

- [ ] #91, #93, #95 are closed.
- [ ] #95's recommendation note exists and #34 references it (replacing the current dangling "#91-95" reference).

## Dependencies

Depends on: none (the #44 output-contract dependency was never load-bearing for the remaining scope)
Parent: #39

## Validation

- #91 and #93's outputs cite official GitHub documentation.
- #95's recommendation note exists and #34 can adopt it as its design basis.