specs/queen/merger_gate.t27 disagrees with the merger it models (unreadable ruleset, pending and zero checks) #7300

Problem

specs/queen/merger_gate.t27 (module QueenMergerGate, written for #5776 in 36a393b) does not describe the merger it is named after, .github/workflows/auto-merge-ready-prs.yml (Find ready PRs), and its header claims a link that does not exist.

1. False header. Line 4 says "The runtime mirrors these functions line for line from t27c gen-js output." t27c gen-js specs/queen/merger_gate.t27 prints fn red_check_passes was not emitted -- this backend lowers declarations, not bodies for all three functions, and the workflow is bash + jq that never reads the spec. Nothing mirrors it.
2. Opposite verdict on one case. The test gate_open_unreadable_fails_closed asserts gate_open(false, true) == false: an unreadable ruleset keeps the gate closed even when every check is green. The workflow opens it. With REQUIRED=null the BLOCKING filter lists only checks that are neither SUCCESS nor SKIPPED, each as "ruleset unreadable, nothing is discountable". Its own self-test pins both halves:
   • tools/bees/merger_gate_selftest.py scenario "ruleset unreadable: a discounted red check still blocks" -> not ready;
   • scenario "ruleset unreadable, every check green" -> ready.
     Review jam: reviewer bee as a service, merger that reads the bee's discounted checks, publisher heading that passes check #5776 item 2 ("An unreadable ruleset fails closed") holds under both readings for a red check. They differ only when everything is green.
3. Two rules the spec does not state. The workflow skips a PR when no check has posted ("zero checks is not zero failures") and when any check has not concluded (PENDING, EXPECTED or an empty state). The spec has neither rule, so a spec-level reader cannot tell that a running check blocks.

Expected

The spec states the rule the merger runs, and says where the two are compared:

• an unreadable ruleset makes every check count as required, so no red is discountable;
• a check that has not concluded blocks;
• zero posted checks blocks;
• the gate opens only when at least one check posted, all concluded, and each one passes.

Every test is one of the self-test's scenarios, named after it. The header names merger_gate_selftest.py as the place where spec and workflow meet, not gen-js.

Decision taken here: the spec follows the workflow on the all-green unreadable case, because the workflow's choice is deployed and pinned by its own self-test, while nothing runs the spec. If the stricter rule (no merge at all while the ruleset is unreadable) is wanted, the change belongs in the workflow (the #5777 lane), and the spec's test flips back with it.

Acceptance criteria

• t27c parse, typecheck and gen for specs/queen/merger_gate.t27 exit 0, and zig test on the gen output passes every test.
• t27c test-report specs/queen/merger_gate.t27 shows 0 vacuous passes.
• tri mutate spec --file specs/queen/merger_gate.t27 kills every mutant, or the commit body shows that each survivor is equivalent.
• No line of the spec claims that gen-js output or any runtime imports it.

Out of scope

.github/workflows/auto-merge-ready-prs.yml and tools/bees/ (the #5777 lane, foreign code).