Plain channels are not wire-compatible with upstream LDK

Two of the RGB extensions in this fork are applied unconditionally, so a channel carrying no RGB data still diverges from upstream rust-lightning. A node built on it cannot open or accept a plain BTC channel with a peer running stock LDK — the funding signature is rejected in both opener directions.

1. commitment_tx_base_weight in lightning/src/ln/chan_utils.rs adds the RGB OP_RETURN weight to every commitment transaction, so the two peers derive different initial commitment transactions. The OP_RETURN only exists on colored commitment transactions, so on a plain channel 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, keyed off the rgb_asset already on FundingScope, leaving RGB behaviour unchanged.

Reproduced on regtest through rgb-lightning-node against ldk-node at rev 16eaa6f, in both directions — see RGB-Tools/rgb-lightning-node#148 for the node-level report and the original signet evidence.

Patch in #36. One open question there: rgb_payment needs a TLV type, and we picked an odd one outside the range the BOLTs may assign, following the convention already used here for skimmed_fee_msat (65537) and hold_htlc (75537). If RGB has a preferred allocation, we will match it.

Note the fix is breaking on the wire 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.

Read lightning/src/ln/chan_utils.rs and trace commitment_tx_base_weight and update_add_htlc, checking how FundingScope exposes rgb_asset. Gate both RGB-specific wire changes on a colored channel while preserving existing RGB behavior, then verify plain-channel compatibility against upstream LDK and RGB behavior through the regtest reproduction described.