A crew reviewer's changes-requested queues the builder's follow-up within one tick, with the review as its brief #1175

Part of #1161 (P7 Command): tonight Sentinel's changes-requested on Mason's pulls (speed-to-lead, listing-launch, deal-clock) started nothing until a person commented, though src/crew/dispatch.ts (pull.reviewed, ~line 390) means to queue a feedback run for a reviewer's verdict.

Done looks like.

• [ ] Name in the pull which step drops it — candidates: emailVerified for an agent actor, skipsFeedback/nothingNew in src/crew/guard.ts not counting an agent's review as new, agentFor on a pull, or the run cap — and fix that step only.
• [ ] In autonomous and assisted, a crew reviewer's changes_requested on a crew pull queues the builder's feedback run with no person speaking; the run's brief carries the review body and its line comments.
• [ ] In off, nothing is queued.
• [ ] test/crew-loop.test.ts: review → follow-up queued with no comment (fails on today's main); off waits.
• [ ] The queued follow-up is visible on the pull page and through the MCP (now lists the run with its reason feedback and the review it answers).
• [ ] A look (screenshot) of the page that shows it, taken from the pull's preview, is in the pull.
• [ ] A test that goes red in this pull is fixed in this pull, whoever's it is.

Files. src/crew/dispatch.ts, src/crew/guard.ts, src/crew/brief.ts, test/crew-loop.test.ts.

Risks. Waking the builder on every verdict could loop with the reviewer; the three-round bound is the next issue, so keep the run cap and breaker in force here.

Fits. Mason (builder brief).

Before pushing. bun x tsc --noEmit and the test files named here, quoted in the pull. One pull, green on its first push.

One pillar: this serves exactly the one it is linked under. Done means reachable on the page, through MCP, in a test and by eye (#334).