Ask the planner what a pull request reaches; map a changed file onto modules in one place (hq ADR 0238)

touchedBy is now the only mapping of changed files onto modules — touched, added, and
read by no build — and reachOfMerge the planner's whole answer with the dependency walk.
The merge handler, the plan what-if, the merge gate's width and composition, and a pull
request's check all ask it, so planning and gating cannot disagree. The gate composes
the definitions of the modules a merge would rebuild or add, not every one in the tree,
and the check says the dependents a merge would build after them.

internal/link/events.go

@@ -221,6 +221,9 @@ type PullUpdated struct {
 	// Paths are the files the pull request changes; PathsTruncated says there were more.
 	Paths          []string `json:"paths,omitempty"`
 	PathsTruncated bool     `json:"paths_truncated,omitempty"`
+	// Removed are the files among Paths the change deletes: a module whose manifest is among them is one
+	// the merge would remove.
+	Removed []string `json:"removed,omitempty"`
 	// ModuleDirs are the directories above the changed files that hold a `module.json` at the head, read
 	// as the merge announcer reads them at a merge commit (issue 278); ModuleDirsSaid says it looked.
 	// What the controller finds a module the graph does not hold yet with: a directory the change adds a
@@ -263,8 +266,10 @@ type CheckLayer struct {
 	Verdict string `json:"verdict"`
 	Summary string `json:"summary"`
 	// Modules are, for the gate, the modules of the mesh's graph the change touches — `new:<dir>` for a
-	// module the graph does not hold yet.
-	Modules []string `json:"modules,omitempty"`
+	// module the graph does not hold yet; Dependents those a merge would build after them because they
+	// stand on them — the planner's own answer.
+	Modules    []string `json:"modules,omitempty"`
+	Dependents []string `json:"dependents,omitempty"`
 }
 
 type Upgraded struct {