docs: row 76 brief requires Sec-Fetch-Site same-origin on the send POST (#1570)

From ops-01's route proposal via Mos (sage-0057).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/plans/2026-10-11_dogfood-cutover.md

@@ -110,7 +110,8 @@ Owner: Dewey, after row 74. Reviewers: Darkwing and Filbert.
 - `POST /api/bus/message` with JSON `{to, body, in_reply_to?}`, at most
   16 KiB. With `--send` it is the one POST preview mode allows. It
   requires the auth header equal to the allowed user on every request,
-  loopback included, an Origin equal to the request's own origin, and
+  loopback included, an Origin equal to the request's own origin,
+  `Sec-Fetch-Site: same-origin` (missing or any other value refuses), and
   `Content-Type: application/json`. It calls `message.send` through the
   same human transport the reads use, with exactly those keys. `to` and
   the body limits are the broker's to refuse; its codes map to HTTP the
@@ -124,8 +125,8 @@ Owner: Dewey, after row 74. Reviewers: Darkwing and Filbert.
   The receipt shows the message id and links its trail; replies show in
   the inbox as today. A draft survives the periodic refresh.
 - Tests: each refusal (no `--send`, missing or wrong header, a loopback
-  request without the header, bad Origin, wrong type, oversize, an extra
-  key), a send through a stand-in transport with exactly the allowed
+  request without the header, bad Origin, a missing or cross-site
+  `Sec-Fetch-Site`, wrong type, oversize, an extra key), a send through a stand-in transport with exactly the allowed
   keys, `outcome-unknown` reported and not retried, and every other POST
   still 403 `read-only`.
 - The README states what `--send` grants: anyone the proxy lets through