fix(bond): reject malformed pay-bond-invoice payloads (empty invoice, zero amount)

[grunch]

Problem

classify_take_reply (rust/src/mostro/pending.rs) accepts a malformed pay-bond-invoice reply as a successful take:

• A PaymentRequest payload with an empty invoice is returned as TakeAccepted with bond: Some(BondRequest { invoice: "" , .. }).
• The bond amount falls back to 0 (.unwrap_or(0)) when both amount and the SmallOrder amount are absent, zero or negative — u64::try_from only rejects negatives, so 0 also passes.

Those values flow through bond_requested into BondInfo and get persisted on the trade row, parking the trade at WaitingTakerBond with a bond the user cannot pay.

Expected

Only a non-empty bolt11 invoice with a positive bond amount yields TakeAccepted with WaitingTakerBond. Anything else is Rejected { reason: "InvalidBondInvoice" }, the same marker already used for a non-PaymentRequest payload.

Tasks

• Reject an empty invoice in the Action::PayBondInvoice branch.
• Drop the unwrap_or(0) fallback; require the resolved amount to be > 0.
• Unit tests: empty invoice, amount absent, amount zero, amount negative (both the amount field and the SmallOrder fallback).
• Check whether the maker-side bond path (add-bond-invoice / order creation) has the same fallback.

Context

Flagged by CodeRabbit on #407 (#407 (review)) as an outside-diff finding. The code predates #407 (it landed with the taker bond work, see #208), so it was split out rather than blocking that PR. See docs/ANTI_ABUSE_BOND.md §6.1.

[codaMW]

I'd like to take this. Confirmed both defects in the PayBondInvoice arm of classify_take_reply: the invoice is never checked for emptiness, and bond_sats uses .unwrap_or(0) and since u64::try_from only rejects negatives, an explicit 0 or absent amount passes as a zero-sat bond.

Approach: require a non-empty bolt11 and a positive resolved amount, else Rejected { InvalidBondInvoice }. Explicit amount stays authoritative when present (an explicit 0 rejects, no fallback); the SmallOrder amount applies only when amount is absent. Leading with a test: commit that fails on main (empty invoice, absent/zero/negative amount, zero-SmallOrder fallback), then the fix.

On task 4: the same pattern is in orders.rs (~L4538, ~L5386) different control flow there, so I'd scope this PR to classify_take_reply and track those as a follow-up unless you'd rather fold them in.