A changed file touches exactly the modules whose build reads it (hq issue 280, ADR 0237)

The builder reads a module's own directory (the repository for one built from its root)
and a repository its recipe packages, nothing else. A file in no module's directory was
read as shared code and rebuilt everything built from the repository: 103 modules for a
merge-check.sh added at the catalogue's root. It now touches nothing, in the merge
handler, the release planner and the pull request's check alike, and the gate says so.

cmd/mesh-controller/checks.go

@@ -22,10 +22,11 @@ import (
 //
 // **The mesh's module graph decides, not the repository.** The controller holds the graph — every module,
 // the repository and directory it is built from — and maps the pull request's changed paths onto it by
-// the rule the merge handler uses (issue 278): a changed file inside a directory holding a module.json at
-// the head is that module's, held or not; a file in no such directory, in a repository modules are built
-// from into that branch, is shared code, and touches every module built from it there. A directory the
-// change adds a module in, which the graph does not hold yet, is a new module and is checked too.
+// the rule the merge handler and the release planner use (whatTheMergeTouched, issue 280): **a changed file
+// touches exactly the modules whose build reads it** — a module's own directory (the whole repository for
+// one built from its root), or a repository its recipe packages. A file no build reads — a script at the
+// root, a README — touches no module. A directory the change adds a module.json in, which the graph does
+// not hold yet (said by the head, issue 278), is a new module and is checked too.
 //
 //   - touches a module: the build seat runs **the gate** — `mesh/merge-gate`, the touched manifests, every
 //     machine composed with the change, the replays — and the repository's own merge-check.sh beside it;