[bug]: Failure to reject `open_channel` with zero `feerate_per_kw`

BOLT 2 requires the receiver of open_channel to reject a feerate that is too low:

The receiving node MUST fail the channel if:

• channel_type does not include zero_fee_commitments and:
  • it considers feerate_per_kw too small for timely processing or unreasonably large.

LND does not enforce the lower bound (nor does it enforce the upper bound, see https://github.com/lightningnetwork/lnd/issues/11149, which is already open). As a result, LND accepts feerate_per_kw = 0.

Impact

A peer can open a channel to an LND node with feerate_per_kw = 0. LND accepts it, resulting in a commitment transaction with zero fee.

• The LND cannot force-close. bitcoind rejects the commitment transaction with min relay fee not met, leaving the LND's funds locked.

• The channel cannot be used. LND already enforces FeePerKwFloor (253 sat/kw) when validating commitment updates in validateCommitmentSanity, rejecting operations (including update_fee(f) where f < 253) below this feerate. As a result, no HTLCs can be added or routed over the channel.

With push_msat = 0, the LND has no balance at risk. With a non-zero push_msat, the LND's funds are locked and cannot be recovered unilaterally. The opener's funds are also locked, so the main issue is that the LND needs the other party's cooperation to close the channel and recover their funds.

Suggested Fix

Reject open_channel when feerate_per_kw < chainfee.FeePerKwFloor. Other implementations already enforce a 253 sat/kw floor when accepting open_channel:

• LDK defines FEERATE_FLOOR_SATS_PER_KW = 253, which is applied when accepting open_channel in new_for_inbound_channel.
• CLN defines FEERATE_FLOOR 253, which is applied when accepting open_channel in fundee_channel.
• Eclair defines MinimumFeeratePerKw = 253 sat, which is applied when accepting open_channel in validateParamsSingleFundedFundee.

Discovery

Found while fuzzing the v1 funding protocol with smite.