fix(seidroid-review): read the finding counts where the driver writes them

[bdchatham]

The bug

check.json carries the counts nested under counts, beside a top-level
conclusion. The step read the three counts at the root.

$ jq -r '[(.blocking // "?"), (.non_blocking // "?"), (.pre_existing // "?"), (.conclusion // "?")] | @tsv' check.json
?	?	?	success
$ jq -r '[(.counts.blocking // "?"), (.counts.non_blocking // "?"), (.counts.pre_existing // "?"), (.conclusion // "?")] | @tsv' check.json
0	2	1	success

The real shape, rendered by running BuildCheckRun on a verdict with two
non-blockers and one pre-existing suggestion:

{"conclusion":"success","title":"2 findings, 1 pre-existing issue","summary":"…",
 "counts":{"blocking":0,"non_blocking":2,"placeable":0,"pre_existing":1}}

Three consequences, all silent

1. The findings line never printed a number. is_count "?" is false, so the
   N blocking | M non-blocking terms were always omitted — which is the whole
   feature feat(seidroid-review): fail soft when the verdict cannot post, and state the finding counts #71 added and sei-load#97
   was opened to pilot.
2. The notice was wrong about the driver. It announced that the driver
   "predates check.json's blocking and non_blocking fields" against v0.11.0,
   which was cut specifically to add them.
3. Both disagreement warnings were dead code. They are guarded by
   is_count "$blocking", so neither could fire. That is the only automated
   cross-check between the verdict comment and the check run — and it was dark
   exactly as a clean conclusion becomes able to post an approval.

Scope

Four characters of path, plus a comment recording why the root read was wrong
so nobody re-derives it. .conclusion was already correct and is untouched.

The sentinel still works for a genuinely older driver: absent counts answer
null at the nested path too, so is_count rejects them and the shorter line
still prints.

Verification

Both jq invocations above were run against the driver's real output.
actionlint reports the same 5 pre-existing findings as the base
(lines 326/1001/1183); none from this change. YAML parses.

Found by a platform review of the pipeline; the driver-side companion is
sei-internal-skills#399.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Workflow-only jq path fix for comment formatting and log warnings; no changes to review logic, credentials, or merge gating.

Overview
The Post the verdict step was parsing check.json for blocking/non-blocking/pre-existing totals at the root, but the driver nests them under counts. The jq expression now uses .counts.blocking, .counts.non_blocking, and .counts.pre_existing (top-level .conclusion is unchanged).

That mismatch silently broke the verdict comment’s Findings line (counts never passed is_count), triggered a misleading notice that the driver “predates” those fields, and kept the workflow’s comment vs check-run disagreement warnings from ever running. A short inline comment documents the correct shape so the root paths are not reintroduced.

^{Reviewed by Cursor Bugbot for commit 9a80f36. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Corrects the jq path for the driver's finding counts from the root to .counts, which is where check.json writes them; the fix is complete (this was the only such read), keeps .conclusion at the root consistent with the workflow's other two consumers of the file, and preserves the sentinel fallback so an older driver still publishes the shorter findings line.

Findings: 0 blocking | 0 non-blocking | 0 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• None at the file/PR level.