RLN cannot open or accept vanilla channels with stock LDK peers

A plain BTC channel between rgb-lightning-node and a peer running stock LDK never opens. It fails in both directions — the funding signature is rejected — and neither operator gets a useful signal:

Got Err message from 026be98c...: Invalid funding_created signature from peer
Channel ffe7b211... closed: funding transaction failed to confirm

Seen first against an ldk-server build on signet, then reproduced on regtest against ldk-node at rev 16eaa6f.

Cause

Two RGB extensions in the vendored rust-lightning are applied unconditionally, so a channel with no asset_id and no RGB amounts still diverges from upstream:

1. commitment_tx_base_weight adds the RGB OP_RETURN weight to every commitment transaction fee, so the two peers derive different initial commitment transactions. (On a plain channel the OP_RETURN is never there, so this is also just overpaying.)
2. rgb_payment is written as a mandatory suffix on every update_add_htlc, so a stock peer's vanilla HTLC is rejected as too short.

Both can be gated on the channel actually being colored, leaving RGB behaviour unchanged.

This matters beyond the error message: RLN nodes carry BTC-only channels too, but today can only form them with other RLN nodes — no inbound liquidity from the wider network, no peering with a non-RLN LSP, not reachable by a stock wallet. There is also no test coverage opening a channel from an unmodified LDK node, so it could regress silently.

Patch

Draft PR at #149, with the fix and interoperability tests covering both opener directions plus a negative RGB case. One open question there: rgb_payment needs a TLV type, and we picked an odd one outside the range the BOLTs may assign, following LDK's own convention for skimmed_fee_msat and hold_htlc. If RGB has a preferred allocation, we will match it.

Note the fix is a breaking change for deployed nodes — plain channels between mixed versions force-close, and RGB channels cannot parse each other's HTLCs — so it needs a coordinated upgrade.

Start by reviewing draft PR #149 and its interoperability tests for both channel-opening directions and the negative RGB case. Confirm that vanilla channels interoperate with stock LDK peers while RGB-channel behavior remains covered, and account for the coordinated upgrade requirement described in the issue.