… buyer/seller axes

Rewrites the anti-abuse-bond spec so that:

- Dispute slashes are solver-directed via a new BondResolution payload on
  admin-settle / admin-cancel, independent of the settle/cancel decision.
  Removes the slash_on_lost_dispute config flag.
- The two axes are made explicit: maker/taker for posting timing
  (apply_to, BondRole, publication gating, supersede-on-retake) and
  buyer/seller for slash logic (timeout responsibility, BondResolution
  payload).
- Phase 2 redefined around BondResolution + InvalidPayload validation
  when a slash targets a party with no Locked bond.
- Phases 4 and 7 reframed in buyer/seller terms with a worked
  responsibility table per order kind.
- New §15 explains the worked cases (uncooperative party in cooperative
  cancel, both-silent, ambiguous evidence) that motivate the decoupling.

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

- `slash_node_share_pct` (default 0.5): on slash, the node retains
  this fraction and the wronged counterparty receives the rest.
  Funds solver/operator work without a new payment rail. Frozen at
  PendingPayout via the new `node_share_sats` column so config
  changes or restarts can't re-balance an in-flight payout. Audit
  event gains `outcome` and per-leg amounts.

- `payout_claim_window_days` (default 15): if the counterparty never
  submits a payout invoice, the bond closes as `Forfeited` (new
  terminal state, distinct from `Failed`) and the node retains the
  counterparty share too. Removes the indefinite-hold failure mode.

Both knobs are exposed in the Mostro info event (§13.1) so users see
the policy before locking a bond. §15.4 covers the rationale.

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

The Phase 1 reuse of `Action::PayInvoice` for the bond bolt11 leaves
clients no type-level way to distinguish the bond from the trade hold
invoice that follows. Worst case is the seller-as-taker (buy-order):
the same user receives two consecutive `PayInvoice` actions and must
disambiguate via memo, hash, or status heuristics.

Two additions to the spec:

- New §6.3 "Client UX considerations" documents the Phase 1 contract:
  bond and trade hold invoice are sequential (never simultaneous),
  the four authoritative methods to distinguish them today (memo,
  local state, status transition, amount heuristic), and recommended
  client behaviour while Phase 1 is the shipped reality.

- New §6.5 Phase 1.5: dedicated `Action::PayBondInvoice` +
  `Status::WaitingTakerBond` in mostro-core. Protocol-only, no schema
  changes, no new slashing — pure ergonomics. Lands before Phase 2 on
  purpose so once `enabled = true` reaches production every client
  routes by action type instead of memo parsing. Includes the naming
  rationale (`Pay…` not `Add…`, matching `Action::PayInvoice`'s
  Mostro→user direction).

Also: rename the deferred-action working name in
`src/app/bond/flow.rs` doc-comment from `AddBondInvoice` to
`PayBondInvoice`; update §14.3 protocol-changes section; refresh §4
phase table so Phase 2 now depends on 1.5.

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

The earlier Phase 1.5 design had mostrod set the order's status to
`WaitingTakerBond` and republish NIP-33 with that status while the
bond was outstanding. That would have hidden the order from the book
and let a malicious or absent taker park an order off-market by
initiating a take and never paying the bond.

The fix preserves Phase 1's actual non-blockability behaviour
(`flow.rs::supersede_prior_taker_bonds`) and codifies it as a
guiding principle:

- New §2 principle 8 anchors the invariant against NIP-69's four
  public buckets: orders with an outstanding taker bond keep
  publishing as `pending` (the bucket), supersede-on-retake works,
  first bond to `Locked` wins.

- §6.5.1 reframes `Status::WaitingTakerBond` as a daemon-level
  status whose load-bearing piece is its mapping in
  `nip33::create_status_tags` → `(true, Status::Pending)`, identical
  to `Status::Pending` on the wire. `take_buy_action` /
  `take_sell_action` must accept both `Pending` and
  `WaitingTakerBond` as pre-trade; transitions on supersede,
  cancellation, and lock are spelled out explicitly.

- §6.5.3 adds a load-bearing non-blockability test:
  `create_status_tags` returns `(true, Pending)` for a
  `WaitingTakerBond` order; a fresh take from a different pubkey
  succeeds; cycling never escapes NIP-69's `pending` bucket until a
  bond actually locks.

- §6.3 gains a non-blockability paragraph + two concrete client
  guidelines: surface `Action::Canceled` clearly when another taker
  wins the bond race; don't gray out the order locally during the
  bond window.

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