Developer definition: the manifest validator always gets a predefined key list, as the checker passes one

The review of hq #517 noted that the checker always passes the predefined key list (the change's when it alters it,
else the trunk's), while the text said only "when the change alters it" (issue 1585).

Claude-Session: https://claude.ai/code/session_01JG73KG7AfSdh6FP8VrBqCn

.claude/agents/mesh-developer.md

@@ -36,8 +36,9 @@ When the change touches any `module.json`, in any repository, run the manifest v
 program `cmd/mesh-judge` in the indexer's module, built at mesh-delivery's trunk, or at the change's mesh-delivery
 head when that head changes the validator itself (then the indexer's own manifest is also validated at the trunk).
 Give it raw manifests, not digests: the trunk's, with the change's laid over them, as the two cases `change` and
-`trunk` the checker's `judgeRequest` names, with the predefined key list when the change alters it. The merge check
-fails a changed manifest the validator refuses or holds, and also an unchanged one in which the change causes a
+`trunk` the checker's `judgeRequest` names, with one predefined key list for both cases, always: the change's when it alters that
+list, else the trunk's. The merge check fails a changed manifest the validator refuses or holds,
+and also an unchanged one in which the change causes a
 problem the trunk case lacks; it says so only after a full build, and no module's unit tests run the validator.
 Report every manifest whose verdict differs between the two cases, with your heads. The reviewer asks for those
 verdicts, and a head reported without them is not reviewed.