fix(source-control): keep the PR monitor's check baseline when a check read fails #7986

Refs: #6877

Agent Brief

Type: Bug
Summary: A failed check read in the PR monitor poll must not reset the baseline, so finished checks are never emitted twice.

Current behavior:
The Monitor poll script reads checks with errors discarded, so a failed read yields an empty check list. The script then stores that empty list as the baseline, and the next good poll emits every finished check again. The first-poll guard counts polls, not successful reads, so a failed first read makes the second poll emit every check that had already finished before the watch started.

Desired behavior:

• A poll whose check read fails (any call in the read errors) leaves the stored baseline unchanged and emits no check lines.
• The baseline-only poll is the first poll whose check read succeeds. A re-arm still emits nothing for checks finished before the watch started.
• A check that finishes after the baseline is emitted exactly once, whether or not failed reads came between.
• Rate-limit handling, comment watermarks and the review-thread read are unchanged.
• The poll contract in the pull-request monitor guidance says the baseline is recorded on the first successful check read.

Key interfaces:

• Monitor poll script contract (name: bucket lines; first poll records only).

Acceptance criteria:

• A new test file, run with scripts/run-test-file.sh, drives the poll script with a stub gh: first check read fails, second returns two completed checks, third adds one more, then the PR reports merged. The test asserts no line for the first two checks and exactly one line for the third.
• The same test covers a failed read between two good polls and asserts no check is emitted twice.
• scripts/check-changelog-fragments.sh passes.

Out of scope:

• The Monitor timeout_ms cap in -p runs (a separate item).
• Comment and review-thread polling.
• The cloud-session fallback poll.

This was generated by AI during backlog shaping. Split from #6877; the owner approved filing it in an attended backlog-shaping session on 2026-10-18.