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