feat(pr-pipeline): carry the lane record in the posted check run's output, not annotations #7772

What

Make lane outcomes read the same way everywhere, and cheaply. Today three readers fetch check-run annotations with one extra REST call per run:

• the pr-unblock dispatchers (limit-stop.mjs through listAnnotations in dispatch.mjs and feedback-dispatch.mjs)
• the morning brief's Lanes section (--lane-read-limit, 200 runs by default; past that the section reads PARTIAL)
• the babysit scripts

Researched against GitHub's docs (verified 2026-10-17), the posted check run's output is the better carrier for a machine record. Annotations are better kept for findings tied to a file and line.

Proposal (fewest moving parts first)

1. Posted check runs (pr-pipeline lanes). report-check-run writes the lane record as one line of stable key=value tokens at the top of output.summary, for example lane=pr-unblock activity=… class=rate-limit resets=… turns=… max-turns=…. The JSON form goes in output.text, and external_id gets <lane>:<run_id>:<attempt>. Readers parse it from the check-run list they already fetch, which removes the per-run annotations call. Keep the feat(pr-pipeline): write the lane record into check-run annotations and lane.json #7766 annotation for one release so readers can switch over, then remove it.
   • Basis: docs.github.com/en/rest/checks/runs. summary and text each have a 65535-character maximum, per the OpenAPI description, and the 2026-03-10 version description gives the same limit. List endpoints return output and cannot filter on external_id.
2. Job-level lanes (ci-workflows reusable workflows: review, intake). These post no separate check run, so the report-lane-outcome workflow-command annotation remains their only record. Keep it, but treat it as capped: the toolkit docs state 10 per type per step and 50 per job. GitHub's REST page names only warning and error per step, an unresolved conflict. User reports say annotations past the cap are dropped silently, but no primary source confirms that.
   • Basis: actions/toolkit docs/problem-matchers.md; docs.github.com/en/rest/checks/runs.
3. Job summaries are for humans only. No REST or GraphQL endpoint returning their content was found (MEDIUM; checked: the OpenAPI description, GraphQL CheckRun, community discussion #27649). No lane reads one, and none should start.
4. Retention. Since 2026-10-01, check runs and statuses follow the Actions retention setting, at most 90 days on public repositories. The morning brief's 7-day window fits that. Build no archive unless a consumer needs more than 90 days.
   • Basis: GitHub changelog, 2026-10-01.
5. Log line. report-lane-outcome already prints the record to the log, where the step-logs endpoint (actions: read) can read it. No change needed.

Done when

report-check-run writes the summary line, and the dispatchers and the morning brief read the record from the check run's output without an annotations call. Existing restarts keep working through the switch-over.

Evidence

The research record (memory tier, not committed) holds 16 accepted claims, three Gaps at MEDIUM and one at LOW, and passed verification on 2026-10-17. It also found that a check run posted with the GITHUB_TOKEN probably cannot use requested actions (LOW, unverified), so do not design around them.

Refs: #7765, #7766

🤖 Generated with Claude Code