ci: version-increment gate should report the comparison it made, not just pass/fail

[MichaelTaylor3d]

Task

The version-increment CI gate reports pass/fail but not the comparison it made. Make it print the
base version, the head version, and the verdict, so a stale bump is visible on the PR instead of being
discovered at merge time.

Why

This has gone stale twice on a single branch (dig-node PR#354) across a five-round gate. The pattern:

1. A lane opens a PR and bumps the workspace version — correct at the time.
2. main moves; another PR takes that version number.
3. Rounds of review pass. Nobody re-checks, because the gate was green when they last looked.
4. At merge, the gate fails with Cargo.toml: base='13.4.0' head='13.4.0' — and the lane has to
   rediscover from scratch what the comparison even was.

A long-lived gate round and a moving main interact badly, and the check is currently remembered rather
than mechanical. It is also cheap to fix: the workflow already computes both values in order to compare
them; it simply does not surface them on success.

Scope

• On every run, success or failure, echo the comparison: base=<x> head=<y> for each manifest checked
  (Cargo.toml and package.json where both exist), plus the verdict.
• Prefer a GitHub step summary or an annotation so it is readable from the PR without opening the log.
• Where both manifests exist, keep the existing must-match check and report both values when they diverge.

Out of scope

Do not change what the gate enforces. This is about making its reasoning visible, not about relaxing or
tightening the rule.

Where

dig-node's version-increment workflow. If the same workflow is templated across repos, say so and name
them — but bound this ticket to a listed set rather than "every repo", so it can actually close
(CLAUDE.md §1.3c rule zero).

Done condition

A PR run shows the base and head versions it compared, on both a passing and a failing run.

Effort

Low — a couple of echo lines into $GITHUB_STEP_SUMMARY in a workflow that already holds both values.

[MichaelTaylor3d]

Lane claimed. Branch loop/360-367-batch, draft PR #368 (batched with #360 #361 #363 #364 #367). Base 4efa57f, v0.154.0 -> 0.155.0. Will comment the outcome here.

[MichaelTaylor3d]

Shipped on #368 (2d643a0)

ensure-version-increment.yml now writes a table to $GITHUB_STEP_SUMMARY on every run, pass
or fail: the base ref actually compared (short SHA of main, plus the head SHA), a row per manifest
with base / head / verdict, the must-match row where both exist, and the verdict spelled out. The
failure text names the two causes seen here -- main taking your version number, and a rebase
dropping the bump as "already upstream" -- with the base SHA to re-bump against.

What the gate enforces is unchanged: same predicate, same exit code, same ::error::
annotations. Out-of-scope respected.

Verified on a passing AND a failing run, as the done condition asks

${GITHUB_STEP_SUMMARY:-/dev/null} keeps the script runnable outside Actions, so the run block was
extracted from the YAML and executed unpiped against scratch git repos:

case	RC	summary
head 0.155.0 over base 0.154.0	0	a Cargo.toml row reading increments, then PASS
main took the number (0.155.0 vs 0.155.0)	1	a row reading does not increment, then FAIL with the re-bump hint
both manifests present and agreeing	0	a row each, plus a both manifests ... agree row

Bounded to a named set, so it can close

dig-node only. Measured across the checked-out submodules: 25 repos carry a byte-identical
copy of this workflow and 6 carry a diverged one -- dig-app, dig-browser, dig-updater,
chip35_dl_coin, dig-framework-adapters, hub.dig.net. Propagating is a follow-up against that finite
list, not "every repo" (CLAUDE.md 1.3c rule zero).