Allow setting a ChannelConfig for LSPS2 JIT channels

[IgnacioPorte]

Hey this PR closes #961.

Context

When acting as an LSPS2 service, the LSP always reuse the node-wide configuration
for the JIT channels it opens towards clients, hard coding their forwarding fees
to zero. An LSP may however want different parameters on client channels than
on its public channels, e.g., different forwarding fees or a different
cltv_expiry_delta.

Changes

Adds an optional channel_config field to LSPS2ServiceConfig:

• If set, the given ChannelConfig is applied as-is to newly-opened JIT
  channels. In particular, configured forwarding fees are charged in addition
  to the channel opening fee.
• If unset (None), behavior is unchanged: we reuse the node-wide config but
  override the forwarding fees to zero, as we're already compensated via the
  channel opening fee.

Compatibility

This is a breaking change, existing LSPS2ServiceConfig initializers need to
provide the new field. I assumed this is acceptable based on the struct's
history.

Testing

Extended lsps2_client_service_integration to pass a custom config and assert
the opened JIT channel carries it.

---

This PR was developed with the assistance of AI tooling (Claude Code).

[ldk-reviews-bot]

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Thanks for looking into this. While I think it makes sense to let the LSP configure certain values, ChannelConfig also has a few fields that don't make sense / we don't want to override (notably forwarding fees, but also stuff like accept_underpaying_htlcs). So it's not the right type for this API. If anything we need to create an LSP-specific channel config variant.

[tnull]

It's odd to reuse the object, but then honor only a few fields of it.

[IgnacioPorte]

Thanks for the review! Read through #478 and I see the problem with the forwarding fees now, the client builds the JIT invoice's route hints before the channel exists, so fees set only in the channel config would never be covered by the sender. Communicating them to the client would need protocol support that bLIP-52 doesn't have today.

I pushed a new version with a dedicated LSPS2ChannelConfig that only exposes cltv_expiry_delta, max_dust_htlc_exposure and force_close_avoidance_max_fee_satoshis. Fees stay at zero and accept_underpaying_htlcs is untouched. Let me know if that make sense.