Say what a pulled lever leaves on the commit the branch was at (#90)

[iderex]

The issue this belongs to

Refs #90, which is closed. This is a correction to a comment block that landed
under it, not a change to any condition on it.

What changed

One paragraph in the header of .github/workflows/branch-health-lever.yml,
saying what a run of that workflow leaves on the commit the default branch was
at when it was dispatched.

What failure it prevents

Somebody pulling the lever while the default branch is at a commit they care
about.

A run reports a check-run against whatever commit the branch pointed at, and a
check-run is not replaced by a later one of the same name. So the pull that asks
for failure marks that commit permanently, and the pull that asks for success
adds a second check-run beside the first rather than clearing it. The header said
how to take the reading and what the lever costs the registry, and said nothing
about this.

This has already happened rather than being a possibility: the merge commit that
landed the workflow carries both conclusions under one name, and it is the commit
the default branch still points at.

Evidence

Run at a35f441cbff92e13fc414a06d854e273af098aa3, the head being pushed. The
paragraph pastes this command and this output:

H=f13c5e341b8d4d3e5eeaf8d2309bef973ea42adc
gh api "repos/Flowfin/core/commits/$H/check-runs?per_page=100" --jq '.check_runs[] | select(.name=="branch-health-lever") | "\(.conclusion) \(.started_at)"'
success 2026-09-02T09:57:46Z
failure 2026-09-02T09:54:16Z

The report's own verdict is unaffected, and that is a reading rather than an
assumption. Run 33616999340, taken after the second pull:

gh run view 33616999340 --repo Flowfin/core --log | grep -E 'recovered     branch-health-lever|No workflow on main'
      recovered     branch-health-lever workflow_dispatch failure 2026-09-02T09:54:12Z f13c5e341b8d4d3e5eeaf8d2309bef973ea42adc 33616634637 - out of the verdict because a later run of it concluded success
No workflow on main is standing red. 20 of the 25 workflow(s) the registry holds were examined.

The document check still resolves every path it reads:

bash .github/doc-paths/doc-paths.sh check | grep 'named path(s) resolved'
ok    72 document(s), 278 named path(s) resolved, 0 excused as examples

The changed set:

git diff --name-only origin/main...HEAD
.github/workflows/branch-health-lever.yml

What this does not cover

Nothing is repaired. A check-run cannot be removed, so the commit the branch
points at keeps the failure conclusion it was given. This adds a sentence and
takes nothing back.

No run was taken for this change, and no workflow was dispatched. The numbers
above are re-reads of runs that already existed.

Nothing measures how anything else reads that commit. The sentence about a
merge button and a dashboard treating a failure among a commit's check-runs as
the verdict is a claim about how such tools generally behave, not a reading of
one, and it is written as a claim.

No trigger, input, default or step changed, so the lever behaves exactly as
it did.

No scope comparison stands behind this. #90 declares no Scope: line at
column zero, so the hygiene check's changed-paths comparison is NOT MADE rather
than made and passed.

Who has read it

Nobody other than the author. There is no second reader on this board tonight,
and the evidence above stands in place of one rather than the question being left
open.