fix: report CCH receive amount including fee

[jjyr]

Summary

• make receive_btc store and report the actual incoming Lightning amount, including the CCH fee
• derive public order amounts from the persisted incoming invoice so legacy orders report what users were actually required to pay
• keep outgoing Fiber fee-rate calculations based on the outgoing principal instead of the incoming total
• add regression coverage for affected legacy orders, pre-fee historical invoices, and principal-based fee limits

Root cause

The receive_btc flow correctly created a Lightning hold invoice for principal + CCH fee, but persisted only the outgoing Fiber principal in CchOrder.amount_sats. The RPC conversion returned that stored value unchanged even though the API contract defines amount_sats as the amount required to pay, including the fee.

A direct replacement with the total would also make the outgoing Fiber fee-rate calculation use the wrong denominator, reducing the effective route-fee allowance. This change therefore derives the outgoing principal from the signed Fiber invoice.

Compatibility

Historical ReceiveBTC orders are normalized from their persisted incoming invoice rather than by blindly adding fee_sats. This preserves orders created before Lightning invoices started including the CCH fee while correcting orders affected by this issue. The serialized order layout is unchanged.

Validation

TDD regression evidence:

• RED: test_get_receive_btc_legacy_order_reports_incoming_invoice_amount failed with stored 98000 versus required 100000
• GREEN: cargo nextest run -p fnn -p fiber-bin receive_btc — 21 passed
• GREEN: cargo nextest run -p fnn -p fiber-bin cch::tests — 126 passed
• cargo clippy --all-targets --all-features -p fnn -p fiber-bin -- -D warnings
• cargo fmt --all -- --check
• git diff --check

Closes #1499

[gpBlockchain]

lgtm