M4b: the redirect checked on the owner's server; finding 1 closed

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/implementer-log.md

@@ -667,3 +667,18 @@ The fault was the design model's, in M4a. Those two posts are two sessions, whos
 their own threads, so the order they reach `loopd` is up to the scheduler: under load, 1 run in 60
 failed. `mm_json.rs` already checks the order of catch-up, so the test now compares the two turns
 as a set (a43d997; 100 of 100 runs under load; tip T32).
+
+**Against the owner's server** (2026-09-24; the same stack as the first review's, built from
+`bfbdccb`). The second account, allowed to talk but not to approve, asked the bot in a direct
+message to read a file that the `ask` grant covers:
+
+| Claim | Seen |
+|---|---|
+| The approval goes to the first approver's direct messages, not the asker's | a new thread in the owner's direct messages; nothing answerable in the asker's |
+| Its first post says who asked, where, and their message | "**Approval 0** was asked by @<second account> in a direct message with the bot. Their message:", then the message, fenced |
+| The approval follows in that thread | the usual post: tool, fenced arguments, grant, taint, expiry, reply line |
+| The asking thread is told | "waiting for approval 0: it was sent to an approver" |
+| The approver answers in the new thread | `!approve 0` there; the post became "✅ Approved by @kyle: the call runs."; the audit log's approval names the owner and that reply's post id; `bxctl audit verify` ok, 3 records |
+| Task 16's sentence | the call was refused with "no tool runner is configured: brokerd.toml has no [runner] section", and the model passed it on to the asker |
+
+Finding 1 is closed.