docs: fix bond doc review findings

- bond_slashed.md: 'cancelled' → 'canceled' (American spelling throughout)
- bond_slashed.md: slash_on_waiting_timeout → bond_slash_on_waiting_timeout
  (correct wire tag name per other_events.md kind-38385 spec)
- pay_bond_invoice.md: 'rumor's content' → 'message's content'
- pay_bond_invoice.md: maker-bond SmallOrder status 'waiting-maker-bond' →
  'pending' (matches flow.rs:380 which uses Some(Status::Pending) as the
  wire-facing NIP-69 bucket; waiting-maker-bond is daemon-internal only and
  never emitted in DM payloads)

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

Author: grunch

src/bond_slashed.md

@@ -2,12 +2,12 @@
 
 The `bond-slashed` action is a notification Mostro sends to a bonded party when their anti-abuse bond has been **settled due to a waiting-state timeout**. It is a forfeiture notice: the bond HTLC has already been claimed into Mostro's wallet by the time this message is sent.
 
-> **Scope.** This action is only emitted on the **timeout slash** path (scheduler-driven, gated by `slash_on_waiting_timeout = true` in the Mostro info event). It is **not** sent on the dispute-slash path — when a solver slashes a bond via [`admin-settle`](./admin_settle_order.md) or [`admin-cancel`](./admin_cancel_order.md), the slashed party receives the `admin-settled` / `admin-canceled` confirmation instead.
+> **Scope.** This action is only emitted on the **timeout slash** path (scheduler-driven, gated by `bond_slash_on_waiting_timeout = "true"` in the Mostro info event — see [Other events published by Mostro](./other_events.md#anti-abuse-bond-policy-tags)). It is **not** sent on the dispute-slash path — when a solver slashes a bond via [`admin-settle`](./admin_settle_order.md) or [`admin-cancel`](./admin_cancel_order.md), the slashed party receives the `admin-settled` / `admin-canceled` confirmation instead.
 
 ## Direction and trigger
 
 - **Direction:** Mostro → the party whose bond was slashed.
-- **Trigger:** The waiting-state timeout elapsed while the responsible party had not performed their expected trade action (e.g. the seller never paid the hold invoice while in `waiting-payment`, or the buyer never submitted an invoice in `waiting-buyer-invoice`), and the operator has configured `slash_on_waiting_timeout = true`.
+- **Trigger:** The waiting-state timeout elapsed while the responsible party had not performed their expected trade action (e.g. the seller never paid the hold invoice while in `waiting-payment`, or the buyer never submitted an invoice in `waiting-buyer-invoice`), and the operator has configured `bond_slash_on_waiting_timeout = "true"` in the info event.
 - The `amount` in the payload is the **slashed bond amount in satoshis** — not the trade amount.
 
 ## Wire format
@@ -45,7 +45,7 @@ The `amount` field in the embedded `SmallOrder` is the **slashed bond amount** (
 After `bond-slashed` is sent to the responsible party, Mostro also:
 
 1. **Cancels or republishes the order** depending on which party was responsible:
-   - **Maker responsible** (e.g. maker-as-seller never paid the hold invoice): the order is **cancelled** (since the maker cannot be trusted to fulfil it). The maker receives the `bond-slashed` notice followed by a `canceled` confirmation.
+   - **Maker responsible** (e.g. maker-as-seller never paid the hold invoice): the order is **canceled** (since the maker cannot be trusted to fulfil it). The maker receives the `bond-slashed` notice followed by a `canceled` confirmation.
    - **Taker responsible** (e.g. taker-as-buyer never submitted their invoice): the order is **republished** to the book as `pending` so the maker can be matched again. The taker receives `bond-slashed` followed by `canceled`. The maker's bond (if any) remains `Locked`.
 
 2. **Asks the winning counterparty for a payout invoice** by sending them an [`add-bond-invoice`](./add_bond_invoice.md) message for their share of the slashed bond (governed by `bond_slash_node_share_pct` — the node retains its share, the rest goes to the counterparty).

src/pay_bond_invoice.md

@@ -16,7 +16,7 @@ The `bond_apply_to` tag in the Mostro info event (kind 38385) tells clients whic
 
 ### Mostro message to the taker
 
-The rumor's content has the same shape as `pay-invoice`; only the action discriminator differs:
+The message's content has the same shape as `pay-invoice`; only the action discriminator differs:
 
 ```json
 [
@@ -94,7 +94,7 @@ When `apply_to` is `"make"` or `"both"`, the **maker** must lock a bond before t
 
 ### Mostro message to the maker
 
-The action and wire shape are identical to the taker case; only the embedded `status` field in the `SmallOrder` differs:
+The action and wire shape are identical to the taker case:
 
 ```json
 [
@@ -108,7 +108,7 @@ The action and wire shape are identical to the taker case; only the embedded `st
           {
             "id": "<Order Id>",
             "kind": "sell",
-            "status": "waiting-maker-bond",
+            "status": "pending",
             "amount": 7851,
             "fiat_code": "VES",
             "fiat_amount": 100,
@@ -125,7 +125,7 @@ The action and wire shape are identical to the taker case; only the embedded `st
 ]
 ```
 
-> Note: `"waiting-maker-bond"` is the daemon-internal status echoed in the DM payload. No NIP-33 order event has been emitted yet at this point.
+> Note: the `SmallOrder` echo always carries `"status": "pending"` — this is the NIP-69 wire bucket the order will appear in once the bond locks and the order is published. The daemon-internal state `waiting-maker-bond` is tracked only in the daemon's database and is never emitted in DM payloads. No NIP-33 order event has been emitted yet at this point.
 
 For **range sell orders**, the bond is sized against `max_amount` (not the individual fiat_amount). The `SmallOrder` echo will reflect the range order fields (`min_amount`, `max_amount`).