charter: a peer lead is answered with fleet_send, not fleet_reply

`fleet_reply` has no route to a peer lead. `AmqpReplyInbox` publishes to
`agent.<target>.inbox` and a lead's own terminal has no such queue, so the
publish is refused. The template told every lead to use it anyway.

Three edits to the canonical block:

- the intent->tool row now says `fleet_send{coordId}`, or `{sessionId}` for a
  peer on the same host, and says plainly that `fleet_reply` is refused
- the prose says WHY: `fleet_reply` resolves a member's blocked `fleet_send`,
  while a peer's coord-id message is durable and non-blocking, so there is
  nothing for it to resolve
- lead<->lead item 3 gains the data-point rule: N observations are N data
  points only if they differ in the axis you are trusting

Wording for all three drafted by the fleet01 lead, who verified the missing
queue namespace independently. The data-point rule has caught three separate
errors in a day, in both directions — one cause blamed for N failures, and
N agreeing measurements that shared one instrument.

Tracked as fleetd #391.

7-Use-Cases.md

@@ -442,7 +442,7 @@ the merge — and merging on a reviewer's word is delegating it by proxy.
 | Answer a member's `fleet_ask` | `fleet_send{turnId, content}` — **not** `sessionId` |
 | Message a **peer lead** on this host | `fleet_send{sessionId: <their terminal>, content}` — `fleet_list` → `leads` reports it. Coordination only, **never** a task |
 | Message a **peer lead** on another daemon or host | `fleet_send{coordId: <their coord-id>, content}` — needs a `coordinator:` block; your own coord-id is in `fleet_list`. Coordination only, **never** a task |
-| Answer a peer lead that messaged you | `fleet_reply{content}` — the one case a lead replies |
+| Answer a peer lead that messaged you | `fleet_send{coordId}` — or `{sessionId}` if they are on this host. **Not** `fleet_reply`: it has no peer route and the publish is refused |
 | Collect a held reply | `fleet_poll{target}` · then `fleet_ack{target, msgId}` |
 | Tear down a member | `fleet_stop{paneId}` |
 
@@ -468,15 +468,21 @@ The traffic between leads is coordination and nothing else:
 3. **Verify a peer exactly as you verify yourself.** Peer status buys nothing: check the claim
    against the code, and re-run the build. A peer's correction gets the same treatment — right or
    wrong on the evidence, not on who said it. Neither of you merges the other's work unreviewed.
+   **N observations are N data points only if they differ in the axis you are trusting.** This cuts
+   both ways. N *failures* blamed on one cause are one data point when the cases share what you are
+   not varying. N *agreeing measurements* are also one data point when they share an instrument —
+   two hosts, two operators and the same formula is one formula, not two confirmations.
 4. **Ask a peer to read your project addendum.** Your addendum is instruction surface: every future
    session on your host obeys it, and a wrong one is obeyed just as faithfully as a right one. The
    author is the worst reader of their own qualifier placement — measured here, one addendum carried
    two defects and a non-author found both. If you have no peer, at least re-read it asking "which
    sentence goes false first, and would a reader reach the caveat before acting?"
 
-Being messaged by a peer does not make you its worker: answer with `fleet_reply`, and push back on
-the substance if it is wrong. A peer that simply complies has thrown away the reason there are two of
-you.
+Being messaged by a peer does not make you its worker: answer the way you would open —
+`fleet_send{coordId}` for another daemon, `fleet_send{sessionId}` on this host — and push back on
+the substance if it is wrong. `fleet_reply` resolves a member's blocked `fleet_send`; a peer's
+coord-id message is durable and non-blocking, so there is nothing for it to resolve. A peer that
+simply complies has thrown away the reason there are two of you.
 
 ### Member (worker or architect) — the turn contract