[carried from previous review]

The assertion for `postil/review` changed from `neutral` to `failure` when findings exist, contradicting the prior design (old comment at line 6069) that deliberately used neutral to avoid green-on-green and breaking consumers or branch-protection rules expecting an advisory neutral conclusion. Confirm this status change is intended and that no branch-protection configuration marks `postil/review` as required, since otherwise merges will now be blocked where they previously were not.

[carried from previous review]

The digest prefix changed from `github-review-receipt-v1` to `github-review-receipt-v2`, the receipt_id prefix changed from `github-review-v1:` to `github-review-v2:`, the version field changed from 1 to 2, and a new `channel` field was added. If receipts are persisted and looked up by receipt_id or deserialized for idempotency checks, existing v1 receipts will not match newly computed v2 receipts, causing every previously published review to be treated as unpublished and re-published. Verify whether stored v1 receipts are migrated or handled, and confirm mass re-publication is intended. Check the receipt storage and lookup code to see how old receipts are treated.

[carried from previous review]

The new channel field on ReviewPublicationReceipt is always set to ReviewPublicationChannel::ReviewComments at line 514, even though this diff introduces a CheckAnnotation publication path (new FindingPublicationOutcome::CheckAnnotation variant and the annotate_findings parameter on complete_checks). If this receipt builder is used for check-annotation publications, the channel will misreport the actual delivery channel, defeating the purpose of the field and causing the hosted service to join lifecycle observations against the wrong channel. Check whether check-annotation publications call this same builder; if so, pass the actual channel through rather than hardcoding ReviewComments.