Produce implementation recommendation

## Type

Research

## Area

GitHub Integration

## Priority

P2 — Medium

## Problem

#34 / PR #112 shipped `skills/github-pr-review/policies/review-status-enforcement.md`,
which already substantively answers most of what this issue originally
asked for (status-mapping design from #92, failure/stale-review behavior
from #94, and the review-decision vs merge-enforcement boundary). #91 and
#93 have been narrowed to their genuinely missing residuals (mechanism
pick + permissions for #91; rulesets-vs-branch-protection comparison for
#93). No consolidated recommendation document exists anywhere, and #34's
body currently claims "Design basis: research issues #91-95" while
linking to nothing, since nothing under this epic was ever produced or
referenced before #34 merged.

This issue is no longer a from-scratch research project — it is a short
consolidation task once #91 and #93 land.

## Goal

Produce one short recommendation note that ties together the mechanism
choice (#91), the ruleset/branch-protection comparison (#93), and the
already-shipped mapping/failure-behavior/boundary substance in
`review-status-enforcement.md` (#92/#94), and point #34 at it as its real
design basis.

## Scope

- Write a short consolidation note (not a new research project) that:
- states the mechanism recommendation and rationale from #91;
- states the rulesets-vs-branch-protection comparison and recommended
detection approach from #93;
- references (does not restate) the verdict→status mapping and
stale/failure behavior already codified in
`skills/github-pr-review/policies/review-status-enforcement.md`;
- restates explicitly the review-decision vs merge-enforcement boundary
(already present in `review-status-enforcement.md` and
`docs/features/github-review-publication.md` — pull it into one place
here rather than re-deriving it).
- Update #34's body to reference this note as its actual design basis,
in place of the current unresolved "#91-95" reference.

## Non-Goals

- Re-researching anything #92/#94 already answered.
- Implementing anything beyond documentation (implementation is already
shipped in `review-status-enforcement.md` via #34/PR #112; this issue is
about making the paper trail accurate, not adding capability).

## Acceptance Criteria

- [ ] Note covers: mechanism (#91), enforcement/ruleset comparison (#93),
and references the existing mapping + failure/stale behavior
(#92/#94) rather than duplicating them.
- [ ] Review-decision vs merge-enforcement boundary is stated explicitly
in the note.
- [ ] #34 is updated to reference this note (not the bare "#91-95" range)
as its design basis.

## Dependencies

Depends on: #91, #93 (narrowed scope); #92, #94 (closed, substance already
shipped — referenced, not reworked)
Blocks: none (#34 already shipped; this closes the paper-trail gap)
Parent: #49

## Validation

- Note reviewed.
- #34 links the note.