openingd: fail channel gracefully when funding\_satoshis exceeds maximum Bitcoin supply

[zhuyh1606-oss]

Fixes #9225

Problem

A peer can crash \openingd\ by sending \open_channel\ with \unding_satoshis\ greater than \WALLY_SATOSHI_MAX\ (21M BTC). The invalid amount flows through to libwally which asserts and aborts the subdaemon.

Three crash variants were found during fuzzing:

1. \unding_satoshis > WALLY_SATOSHI_MAX\ alone → assert in \psbt_input_set_wit_utxo\
2. \unding_satoshis\ and \push_msat\ both exceeding the supply → assert in \�itcoin_tx_add_output\
3. Individual outputs under the cap but total exceeding → assert in \wally_tx_add_output\

Fix

Add a bounds check in both the \initiator\ and \undee\ paths. If \unding_satoshis > chainparams->max_supply, fail the channel with a proper error message instead of crashing.

The single check on \unding_satoshis\ covers all three variants since the commitment tx outputs are derived from \unding_satoshis.

Changelog-Fixed: openingd no longer crashes when a peer sends open_channel with funding_satoshis above the maximum Bitcoin supply.

[Andezion]

What do you think about moving the max_supply bound into check_config_bounds() in openingd/common.c? This is the existing shared validation helper for funding amounts and is already called from every path that needs this protection (both funder/fundee in openingd.c, and all four call sites in dualopend.c). dualopend.c appears to have the same unbounded-total pattern with no max_supply check

[Andezion]

Did you check whether dualopend.c has the same unbounded-total issue when building its commitment transaction?

[Andezion]

Is there a reason you added the check at two separate call sites instead of inside check_config_bounds(), given that function already receives the funding amount at every relevant call site?