Developer and reviewer definitions: validate every changed manifest before handing back

The take-in group's first check failed after a full build on a manifest the
validator refused (an indexer's own stream outside the bus's forms); no local
run had validated the changed manifests. The developer now runs the manifest
validator as the checker does and reports each verdict; the reviewer asks for it.

Issue 1585.

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

.claude/agents/mesh-code-reviewer.md

@@ -29,6 +29,8 @@ against the records, never limits on what you check: a ruling that contradicts a
   function where the repository is over budget, real sleeping;
 - vet or tests that fail: run `go vet ./...`, `go vet -tags integration ./...` and `go test ./...` in every
   touched module, as the running checker places siblings.
+- a changed `module.json` without the manifest validator's verdict from the developer, or with one that refuses
+  or holds it: the merge check would fail on it only after a full build.
 
 Anything else (hardening, a further case, a nicer form) is a note, never a round. Read only: no edits, no git
 write, no verb that writes, never ssh. Use a temporary directory under `/var/tmp`.

.claude/agents/mesh-developer.md

@@ -32,6 +32,12 @@ sleeping. Run `go vet ./...`, `go vet -tags integration ./...` and `go test ./..
 the running checker places siblings (playbook 07). Use a temporary directory under `/var/tmp` (TMPDIR). Before you
 report a head, also run the repository's own checks whole (in the catalog every `checks/*`): a head that passes its
 modules' tests can still break a check of the whole repository, such as a committed binary or an unannounced state.
+When the change touches any `module.json`, in any repository, run the manifest validator over every manifest of the
+mesh with the change's heads laid over the trunk, as the checker does: the program `cmd/mesh-judge` in the indexer's
+module, built from the change's head of mesh-delivery, given the request the checker's `judgeRequest` builds. A
+manifest the validator refuses or holds fails the merge check only after a full build, and the unit tests of the
+module that owns it do not run the validator; report each changed manifest's verdict with your heads. The reviewer
+asks for those verdicts, and a head reported without them is not reviewed.
 Start no agents of your own: the lead decides who works on what.
 
 **Stop at about two thirds of your context.** Commit what is done, write a section under your agent label at the