TRI CLAW: one-click formatter suggestions on PRs -- suggest.t27 law (lanes pr-files, pr-suggestions of #10277) #10285

Problem

The TRI CLAW GitHub App holds pull_requests write, but nothing uses it for .t27 yet. When a PR changes a .t27 file that t27c fmt would rewrite, the author only learns it from a red check and has to run the formatter by hand. The pr-files (pull_requests read, GET /pulls/{n}/files) and pr-suggestions (pull_requests write, POST /pulls/{n}/reviews) rows of the surface table (#10280, lane of epic #9271) are planned but have no law behind them.

Proposal

specs/claw/suggest.t27 (new): the law that decides whether and where a formatter suggestion may be posted, so TRI CLAW can post one review whose comments are suggestion blocks that the author accepts in one click.

• The review event is always COMMENT; APPROVE, REQUEST_CHANGES and anything unknown map to "post nothing".
• Comments anchor on the RIGHT side only.
• A hunk outside the diff is skipped; a multi-line range must sit inside one diff hunk. Diff ranges come from the @@ -a,b +c,d @@ headers of the patch field of pr-files, parsed in the spec.
• At most 20 comments per review and 40 lines per suggestion.
• An unknown hunk (unknown kind, line 0, inconsistent count, overlap) poisons its file: nothing is posted for it.

The workflow that fetches the file list, runs the formatter and POSTs the review is a separate, owner-gated step (workflow YAML is foreign code under the own-language gate).

Boundary

• specs/claw/suggest.t27

User Scenarios

• Given a PR that changes specs/a.t27 where the formatter would rewrite lines 11-12 and both lines are in the PR diff, when the plan runs, then those lines get one comment with event COMMENT, side RIGHT.
• Given a formatter hunk on a line the PR did not touch, when the plan runs, then the hunk is skipped and the review is not rejected by GitHub.
• Given a requested event of APPROVE, REQUEST_CHANGES, PENDING or an empty string, when the event is chosen, then nothing is posted.
• Given 25 eligible hunks, when the plan runs, then 20 are posted and 5 are capped.
• Given a hunk of unknown kind in a file, when the plan runs, then nothing is posted for that file and other files are unaffected.

Requirements

• FR-001: The review event MUST be COMMENT; no input MAY reach APPROVE or REQUEST_CHANGES.
• FR-002: Comments MUST use side RIGHT only.
• FR-003: A comment MUST NOT be planned for lines outside one head-side diff range of its file.
• FR-004: A review MUST carry at most 20 comments, and a suggestion MUST span at most 40 lines.
• FR-005: An unreadable hunk MUST withhold its whole file (fail closed).
• FR-006: A review with no comment MUST NOT be posted.

Success Criteria

• 16 of 16 tests pass under t27c test-report on the Railway lab, with 0 vacuous passes, including the test "event is never APPROVE".
• A mutant that lets event_for return its input fails the suite.
• t27c spec-status reports IMPLEMENTED.