Soften two over-precise claims from #209 (one is in a merged commit message)

[monkopedia-coder]

Two over-precise claims from #209 — both in the merged commit message, so they cannot be edited in place

Category: correctness of a durable claim (precision, not behaviour)
Found by: the #209 re-reviewer, raised non-blocking and approved around. Recorded here so the record is
correctable rather than lost.

PR #209 (merged 2cd2559) declined gradle/actions/setup-gradle — whose v6 moved caching into a
non-MIT component — and kept only gradle/actions/wrapper-validation@v6. That decision is correct and
was verified from Gradle's own artifacts, five independent ways: the DISTRIBUTION.md component map
places wrapper validation inside the MIT "Action Runner"; LICENSE/NOTICE scope the carve-out to the
single gradle-actions-caching component; wrapper-validation/action.yml has no cache input at all
(3 inputs), so caching is structurally impossible rather than merely switched off; the bundle greps 0/0/0/0
against setup-gradle's 1/1/1/2; and — the strongest — setup-gradle reaches the component through a
runtime dynamic await import(".../sources/vendor/gradle-actions-caching/index.js") guarded by
isCacheDisabled() / provider==="basic" / else, a call site wrapper-validation does not have.

Nothing below disturbs that conclusion. Both items are wording that claims more than the evidence supports.

1. "No gradle.com Terms of Use are accepted anywhere in this repository" — overshoots

The proprietary blob (2,318,919 bytes) physically ships in the action checkout, and
licenses/gradle-actions-caching-license.txt binds on "downloading, installing, or using". So something
is downloaded even though nothing loads it.

This is not a defect in the decision: Gradle's own documented opt-out (cache-provider: basic) downloads
the identical blob, so "present but never loaded" is the vendor's own standard for declining, and #209
clears it by a wider margin — it removes the call site entirely rather than switching a flag.

Correct wording: "…accepted by anything this repository executes; the proprietary component is present
in the action checkout but is never loaded."

Appears in both the PR body and the merged commit message for 2cd2559. The commit message cannot be
amended on main, which is exactly why this is written down.

2. "A superset of gradle-home-cache-includes' default" — not a superset

caches + wrapper is described as a superset of that default. It is not: the default is
caches\nnotifications\n, so the new set drops notifications while adding wrapper. Immaterial in
effect — nothing depends on cached notifications — but "superset" is a false relation and will mislead
whoever next tunes the cache.

Also confirmed accurate, so nobody re-derives it

The capability audit against setup-gradle@v4's 41 parsed defaults is right on every row: validate-wrappers
was silently ON and is preserved; gradle-version, dependency-graph, build-scan-publish and
arguments were genuinely unused; add-job-summary and cache cleanup/dedup are lost and disclosed.
The release.yml worst case is clean — all four Gradle invocations use ./gradlew, with zero bare
gradle calls across all four workflows, so the lost Gradle-installation capability is inert on the publish
path.

Effort: trivial — two sentences. Suitable to ride along on any later CI touch rather than its own PR.

Refs #207, Refs #231.

[monkopedia-coder]

A third item for this issue, same class: a boundary recorded as narrower than it is

Adding here rather than filing separately, since this issue is explicitly the place for
precision-not-correctness wording that should ride along on the next CI touch.

.github/test-evidence-gate/verify.sh:252-257 (added by PR #244, merged 51f237a).

Those lines record an honest and important boundary: of the 16 ::error::/exit 1 pairs across the four
workflows, 10 are covered by the verdict run (the block is executed and judged on exit status) and
6 are covered only statically — an awk check asserting each annotation is immediately followed by
exit 1. The comment says which six, why they are unreachable from the harness, and that they get
"the same invariant statically instead."

What it never says is that the evidence is weaker in kind. A static adjacency check proves the two
lines sit next to each other; it does not prove the exit ever fires. Those are different claims, and
"the same invariant, statically" reads as though only the method changed.

Suggested replacement, from the #244 reviewer (zero behaviour change, one line):

proves ADJACENCY, not EXECUTION; these six exits have never been observed to fire

Why this is worth the line. This whole thread — Refs #239, Refs #240, Refs #242, Refs #243 — exists
because gates reported success while measuring nothing. A note saying "we could not execute this, so we
asserted a weaker thing" is a durable weakening, and it goes unexamined the moment it is written down.
The remedy is to state the weakening in the terms that make it re-checkable later, not in terms that
make it sound equivalent.

Two things measured during #244's review that should NOT be re-derived — record them so the next
reader does not have to:

• The unreachability is real, not assumed. With an empty file list (xml=(); xml_files=()) all five
  extracted blocks exit 1 via the zero-executed guard; with a nonexistent path, ${#xml[@]} reads 1, so
  the emptiness guard is not merely unreached — its condition is not even false. Across all ten extracted
  blocks, No JUnit XML = 0 and any glob assignment = 0, against positive controls of 1/1/2/1 in the
  workflow sources. The extractor anchors on sum_attr() {, which sits strictly after the glob at every
  site.
• The static tier does not rot silently. Inserting a plausible third guard into compiler-check.yml
  gives expected 16, got 17 on both assertions. The hardcoded 16 is load-bearing: any growth in the
  gate reddens and forces a human back into this file. That is what makes the weaker tier acceptable
  rather than merely admitted.

Refs #244, Refs #243, Refs #239.