ci: report corpus baseline drift on a cadence instead of by accident - #2196

`tests/baselines/README.md` documents the CI behavior for this manifest
and is where someone goes to understand it, so a second workflow acting
on the same file belongs there. Without it the cadence job reads as
duplicate coverage, and the natural next move is to delete one.

The section names the two reasons the PR gate cannot see this class --
an unmanifested downloaded file warns rather than fails, and the corpus
cache is keyed on the fetch script rather than on upstream state -- so
the distinction survives past whoever remembers the incident.

Also two guards on the script: it refuses to run outside the repository
root, where its relative paths and its `git checkout --` would either
fail confusingly or resolve somewhere unintended; and the comment about
always exiting 0 now says what that covers. Drift is reported rather
than gated, but `regenerate()` runs under `check=True`, so a corpus file
that panics the parser still fails the step -- that is a real problem on
main and nightly-health picks it up from there.

`gh()` returned an empty string when the command failed, which is
indistinguishable from a successful empty result. For a job whose only
output is an issue, that conflation is the worst bug available:

  * a failed `issue list` looks like "no existing issue", so the next
    run opens a duplicate, every week;
  * a failed `issue create` yields a blank URL, prints "opened ", and
    leaves the workflow GREEN having reported nothing at all.

The second is exactly the silence this workflow exists to break, wearing
a green check -- the same failure `nightly-health.yml` was written for,
reproduced inside its sibling.

`gh()` now raises `GhError`, and `main` turns that into a non-zero exit.
Finding drift stays exit 0, because a red X for a successful report
would be one more failing scheduled workflow for nobody to notice;
failing to report is the opposite case. A job that cannot say what it
found must not look like a job that found nothing.

Self-tested in both directions by stubbing `subprocess.run`: returning
"" on failure fails the test, and so does raising on a successful empty
result, which is a real and different answer.

Also makes the two list-element string concatenations explicit --
CodeQL's `py/implicit-string-concatenation-in-list`, flagged in review.
Adjacent literals on consecutive lines inside a list read as a missing
comma, and in a list of issue-body paragraphs that is a plausible typo
rather than a pedantic one.

The baseline test already refuses to write a manifest from fewer than
`MIN_FULL_CORPUS_SIZE` (100) files, so a partial fetch cannot silently
produce a truncated manifest and a false "no drift" -- checked, and it
panics rather than skipping when `BASELINE_UPDATE` is set.

That backstop and this check are not redundant, and the note says why:
at a corpus of ~735 this one trips at ~685, so a merely partial fetch
gets a sentence explaining itself instead of a cargo stack trace, and
the test's assert stays what it was written to be -- a last resort
against truncating the committed manifest, not the routine path.

Someone reading either guard alone would reasonably conclude the other
is dead weight.

The "Changed hashes" section told the reader "the diff says which: a
changed source hash is upstream churn; a changed output hash with an
unchanged source hash is a parser change that reached main without
regenerating" -- and then printed a list of paths and no diff. It knew
the answer and sent the reader to find it.

`classify` already had both sides of every changed line, so it now
compares the source hashes and splits the group in two. They are not a
matter of emphasis:

  * source hash moved   -> the file's contents changed upstream, a
                           different output hash is expected, routine.
  * source hash IDENTICAL, output hash moved -> this repository produces
                           different output for the same bytes than the
                           committed baseline records. That is a parser
                           change that reached main unregenerated, and it
                           is the reason this job exists.

Collapsed into one list they look the same and read as churn, which is
how the second kind gets skimmed past.

Self-tested in both directions: forcing every rehash to read as upstream
fails, and so does forcing every one to read as a parser change. The
second control is the one that matters -- a split that always cries
"parser change" would be noise nobody acts on within a month.

…mpty

Two CodeQL findings from review, both in code this branch added.

`py/implicit-string-concatenation-in-list`: nine runs of adjacent string
literals now join with an explicit `+`. Wrapping them in parentheses was
not enough -- adjacency inside parentheses is still adjacency, and the
concern is real for these in particular, since they are paragraphs of an
issue body where a missing comma would silently merge two of them rather
than raise.

Verified the rewrite changed nothing: rendering the same diff through
the pre-rewrite and post-rewrite modules gives a byte-identical body
(sha e0194f7e3082a81a both sides).

`py/empty-except`: the self-test's `except GhError: pass` is the
assertion -- reaching that arm is the pass condition and the
`failures.append` above it is what runs otherwise -- but nothing said
so, and a bare `pass` under an `except` is worth explaining every time.