Reviewer bee: a cancelled master run is not red, apply the merger_gate rule before writing discounted-check #7345

The reviewer bee (tools/bees/reviewer.py, launchd job ai.t27.reviewer-bees) still reads a CANCELLED master run as "red on master too", so it writes a discounted-check: line for a pull request's own red check.

PR #7320 (Closes #7317) fixed the merger side: the merger discounts a red only when master's newest COMPLETED run of the same check, at or after the PR's merge base, FAILED. Cancelled, skipped, running, queued, timed-out or missing runs are passed over; with no completed run the answer is UNKNOWN and the PR is blocked. The rule lives in specs/queen/merger_gate.t27 (run_says, look_back, discount_holds).

The reviewer must apply the same rule, or it keeps approving pull requests the merger then refuses.

Where the reviewer goes wrong today:

• RED_ON_BASE counts cancelled, timed_out, action_required and startup_failure as red on the base branch (blame, used by queue).
• The brief gives the agent the newest base commit's raw conclusions (Facts.on_base), and the runner accepts any discount the agent writes. Nothing stops a discount of a red whose master run was cancelled.

What to do:

• Mirror the merger's master read in the reviewer, with a pointer to specs/queen/merger_gate.t27; no second rule.
• Show the agent what the merger will read on master for each red check.
• When master is not red (green or UNKNOWN) for a red check, emit no discounted-check: line for it: an APPROVE becomes REQUEST_CHANGES, as the B16 gate (pr_caused) already does.
• Self-test scenarios: master cancelled -> no discount; master failure -> discount; newest cancelled with an older failure at or after the merge base -> discount; master success -> no discount. They must fail on the old code.

Context: reviewer.py lives on the branch of PR #5777, which is not on master and cannot merge cleanly (it conflicts with master in four files). The fix lands where it can merge.