Inbound add-invoice from the daemon is not handled — maker-buyer trades die by timeout

[Catrya]

The kind-14 ingest (dispatch_mostro_message in rust/src/api/orders.rs) has no arm
for an inbound Action::AddInvoice — it falls into the catch-all that only logs.
AddInvoice is only handled as a reply to our own take (classify_take_reply).

But add-invoice is exactly what the daemon sends to a maker buyer: they create
a buy order, a seller takes it and pays the hold invoice, and the daemon then asks
the buyer for their invoice. Since the message is dropped, the trade status never
becomes WaitingBuyerInvoice, the UI never offers the add-invoice action, and the
daemon cancels the order by timeout.

Reproduction (real daemon, order 56c1d85b)

1. Created a buy order as maker; a seller took it.
2. 23:34:59 — WaitingSellerToPay arrives → handled, status synced to WaitingPayment.
3. 23:35:20 — AddInvoice with Payload::Order(status=WaitingBuyerInvoice, amount=484)
   arrives, decrypts fine — and nothing happens (no status log line follows; catch-all).
4. 23:35:21 — a second AddInvoice with Payload::Peer (counterparty reputation) — also dropped.
5. 23:36:35 — daemon cancels the order by timeout: the user was never asked to act.

Proposed fix

Add an Action::AddInvoice arm to the ingest, mirroring the existing PayInvoice arm:

• Payload::Order variant → persist status WaitingBuyerInvoice + sats amount to the
  order book and trade DB (keyed by the message's order_id — the message arrives with
  trade_index=None on the global subscription, so the order id is the only key).
• Payload::Peer variant → ignore for now (reputation info).

With the status persisted, the existing MyOrderScreen polling already navigates the
maker buyer to the add-invoice screen (waitingBuyerInvoice && !isSelling branch).

Side effect fixed too: the buyer's trade no longer shows the misleading WaitingPayment
status (inherited from WaitingSellerToPay) while it's actually the buyer who must act.