claw/t27f: one check-run annotation per row that is not sealed, at most 50 per request #10298

The claw/t27f check-run (landed in #10283, Closes #10268) says what is wrong only in its summary table. A reviewer has to open the check, read the table and match each row to a file by hand. GitHub check-runs can carry annotations instead: one note per file, shown next to the file in the pull request diff. The API takes at most 50 annotations per request, so a run with more rows posts the first 50 with the check-run and adds the rest with PATCH requests on the same run.

specs/claw/github_surface.t27 (#10280) already names this surface as the check-annotations row, and requires the same three-scope installation token the check uses today: checks write, pull_requests read, contents read.

Shape of the change:

• The law decides everything: which rows get an annotation (every row whose verdict is not sealed), its level (notice for a neutral row, failure for a failing row, warning for a failing row in a reporting consumer such as the published mirror), its title and message, and the batch size of 50 (ANNOTATIONS_PER_PATCH). It writes one tab-separated line per annotation and a --batch line between batches.
• The shell in the claw-t27f job only splits on --batch, sends the first batch with the POST, and sends each further batch with a PATCH.
• The offset for the added workflow lines is the deletion of a spent wave generator whose port to .t27 landed in Port scripts/gen_w381_lean.py (Python, 8 functions) to specs/port/scripts/gen_w381_lean.t27 #6910.

Boundary

• specs/claw/t27f_gate.t27
• specs/claw/t27f_gate_pins.t27
• gen/c/claw/t27f_gate.c
• .trinity/seals/claw_ClawT27fGate.json
• .trinity/seals/claw_ClawT27fGatePins.json
• .github/workflows/gate-topology.yml
• scripts/gen_w381_lean.py

User Scenarios

• Given a pull request that edits one sealed spec without resealing it, when the claw-t27f job runs, then the check-run carries one failure annotation on that file titled T27F seal: stale-seal, with a message that says how to reseal it.
• Given a pull request that adds 120 specs with no seal, when the job runs, then the POST carries 50 notice annotations and two PATCH requests carry 50 and 20 more.
• Given a pull request whose changed specs all verify, when the job runs, then the check-run carries 0 annotations.
• Given the published mirror gHashTag/ghashtag.github.io with a stale seal, when the job runs, then its annotation is a warning, never a failure.
• Given the scope input is unreadable, when the law reads it, then it writes no annotation and the check-run still fails closed.

Requirements

• FR-001: specs/claw/t27f_gate.t27 MUST define ANNOTATIONS_PER_PATCH as 50 and MUST cut its annotation output into batches of at most that many.
• FR-002: Every row whose verdict is not sealed MUST get exactly one annotation; a sealed row MUST get none.
• FR-003: The annotation level MUST follow the row conclusion: notice for neutral, failure for failure, warning for failure in a reporting consumer.
• FR-004: No annotation text MUST hold a tab or a newline.
• FR-005: The job MUST send at most 50 annotations per request and MUST use the same installation token scoped to checks write, pull_requests read and contents read.
• FR-006: gen/c/claw/t27f_gate.c MUST be regenerated by t27c gen-c, the two seals MUST be remade, and the change MUST delete at least as many hand-written foreign lines as it adds.

Success Criteria

• git diff --exit-code -- gen/c/claw/t27f_gate.c exits 0 after regeneration.
• 0 vacuous checks in the two claw specs, and every claw seal verifies.
• The change adds 0 foreign lines net.