openingd: fail open_channel at receipt when our dust limit exceeds their reserve

[Amperstrand]

BOLT #2 requires the accept_channel sender to set dust_limit_satoshis
less than or equal to channel_reserve_satoshis from the open_channel
message. CLN's fundee_channel() quotes this exact MUST in its comment
block but implements no check for it: with the chainparams dust limit
(546) and an opener reserve below that, CLN replies accept_channel
with dust_limit_satoshis=546, violating the sender MUST. A
spec-strict opener then fails the channel (the reporter's LDK LSP sits
at the 354-sat floor the spec itself mandates as the minimum dust
limit); nothing above DEBUG on our side records why (#9439).

This adds the mirror of the existing opener-side check (dust limit … would be above our reserve, openingd.c:446-455) to the accepter path,
respecting --dev-allowdustreserve like both neighboring checks.

Notes for reviewers:

• The opener side already enforces the same rule when CLN opens (fails
  an accept_channel whose dust exceeds our reserve) — two unpatched
  CLN nodes reject each other in this shape (the opener under
  --dev-allowdustreserve; a stock fundchannel self-bumps its
  reserve to 546, so the violating open is unreachable without it).
• The quoted-MUST comment block sits under "Pending proposal to remove
  these limits." — but until the bolts change, the MUST stands, and
  stock CLN violates it against strict peers today.
• Verified on the official v25.02 / v26.06 / v26.06.7 binaries and the
  docker v26.06 tag with a BOLT8 wire peer: the violation reproduces
  at every reserve below 546 I probed (354, 545), clean at 546.
• The in-suite test runs the opener under --dev-allowdustreserve to
  send a true sub-546 reserve (same crutch as test_zeroreserve); it
  fails on master and passes with this change.
• With the check in place a spec-strict peer no longer needs to error:
  CLN fails first, at open_channel receipt.

pre-fix wire journal (v26.06.7): accept_channel with dust_limit 546 against opener reserve 354 — expand

"kind": "accept_channel", "dust_limit_satoshis": 546, ... "channel_reserve_satoshis": 1500,
  "channel_type": "401000"   (opener's open_channel carried channel_reserve_satoshis: 354)

post-fix (pr9439): rejection at open_channel receipt + the inclusive 545/546 boundary — expand

"kind": "wire_error", "data": "You gave bad parameters: Our dust limit 546sat would be above their reserve 354sat"
boundary-r545: accepted=NO  ... would be above their reserve 545sat
boundary-r546: accepted=YES (accept_channel; 546 > 546 is false — the MUST is <=)

Fuller validation record — every cell, the four-version matrix, the red/green transcript, and the repro recipe: https://gist.github.com/Amperstrand/880bf568f792db0227666e9472d2c9b5

Fixes #9439

[Andezion]

Given dualopend.c (v2 / dual-funding) has no equivalent reserve/dust cross-check at all, and the issue flags that a channel under ~~54,600 sat can hit the same class of problem there (derived 1% reserve below 546) - is a follow-up planned for that path, or is it intentionally left out because the reserve there is derived rather than negotiated?

[Amperstrand]

Intentionally left out — the derivation closes it. v2 floors the reserve at max(1% of total, dust_limit) on both sides (the clamp in dualopend.c's set_reserve, per the spec's own rule), so the sub-54,600 case floors both reserves at 546 rather than below dust. The dead-channel shape needs both initial balances at or under reserve, i.e. total <= 2x reserve — check_config_bounds rejects that arithmetic at every dualopend site, and above 54,600 it's outright impossible (2x1% < total). One side under its reserve is fine: the spec notes it "may not be met" initially, and v2 lets the accepter fund zero. The shared initial_commit_tx backstop still fails loudly if it ever sees it. Happy to open a follow-up if you see a shape I'm missing.