Per-channel accounting: attributing revenue and on-chain costs #1209

I proposed per-channel profitability tooling in ldk-server (lightningdevkit/ldk-server#298, PR lightningdevkit/ldk-server#316) and benthecarman's answer was that it largely needs to be built into rust-lightning/ldk-node instead. That makes sense to me, since all the inputs live here, so I'd like to ask where it belongs before writing anything.

The question an LSP operator wants answered is "is this channel paying for itself?". Everything needed is already in ldk-node, just not connected:

• revenue: ForwardingAnalytics gives total_fee_earned_msat and total_skimmed_fee_msat per channel (the latter covering LSPS2 JIT opening fees), plus counts and timestamps.
• costs: the payment store records on-chain payments with fee_paid_msat and a TransactionType (Funding, CooperativeClose, UnilateralClose, AnchorBump, Claim, Sweep), and those variants carry the channel id and counterparty.
• missing: closed-channel history, which is where most of the cost lands. That's Add persistent closed channel history and list_closed_channels() #882, still open and waiting on whether the history should live in LDK instead.

Today a consumer has to paginate the whole payment store and join it against the analytics on channel ids. That's identical work for every ldk-node user, and it can't be done completely while closed channels are invisible.

Shapes I can see, and I don't have a strong preference:

1. Extend ForwardingAnalytics with the cost side, so per-channel stats carry both revenue and attributed on-chain costs.
2. A separate accounting API (node.accounting() or similar) that joins the two stores.
3. Just expose the primitive: a way to fetch on-chain payments attributed to a channel, leaving the arithmetic to callers. Smallest change, and useful on its own.

Is this something you'd want in ldk-node, and if so which shape? Also worth settling whether any of it belongs in rust-lightning instead, which is the same question #882 is stuck on.