Count zero-fee-commitments channels in anchor reserve check

[tnull]

can_support_additional_anchor_channel decides whether the wallet has enough on-chain reserve to back another anchor channel by counting the node's existing anchor channels. The classification only checked the anchors_zero_fee_htlc_tx feature, so channels negotiated with the anchor_zero_fee_commitments (TRUC / 0FC, option 41) variant — which require the same on-chain reserve to fund commitment / HTLC fee bumps on force-close — were silently dropped from the count.

A node enabling negotiate_anchor_zero_fee_commitments would therefore be green-lit to open more anchor channels than its wallet can actually back, risking unfunded fee bumps and HTLC loss on simultaneous force-closes.

Treat both feature flags as marking a channel as an anchor channel for reserve-accounting purposes (factored into a small is_anchor_channel_type helper, used in both the chain-monitor and channel-manager loops), and add a regression test that opens a single 0FC channel with reserves sized for exactly one channel and asserts the function refuses to authorize a second.

Co-Authored-By: HAL 9000

[ldk-reviews-bot]

👋 I see @tankyleo was un-assigned.
If you'd like another reviewer assignment, please click here.

[ldk-claude-review-bot]

No issues found.

The fix is correct: is_anchor_channel_type() properly checks both supports_anchors_zero_fee_htlc_tx() and supports_anchor_zero_fee_commitments(), and is applied to both the ChainMonitor loop and the ChannelManager loop. The regression test correctly validates that a 0FC channel is counted.

Cross-cutting observation (pre-existing, outside this PR's diff): Several weight functions in lightning/src/ln/chan_utils.rs have the same class of bug — they only check supports_anchors_zero_fee_htlc_tx() without also checking supports_anchor_zero_fee_commitments(), including commitment_tx_base_weight(), htlc_success_tx_weight(), htlc_timeout_tx_weight(), and the aggregated weight helpers. These would return non-anchor weights for 0FC channels. The reserve calculation in this file is unaffected since it uses its own hardcoded constants that match the anchor weights, but the functions in chan_utils.rs may warrant the same treatment in a follow-up.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.27%. Comparing base (1a26867) to head (33987e8).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4592      +/-   ##
==========================================
- Coverage   86.84%   86.27%   -0.57%     
==========================================
  Files         161      159       -2     
  Lines      109260   109197      -63     
  Branches   109260   109197      -63     
==========================================
- Hits        94882    94210     -672     
- Misses      11797    12374     +577     
- Partials     2581     2613      +32     

Flag	Coverage Δ
fuzzing-fake-hashes	?
fuzzing-real-hashes	?
tests	86.27% <100.00%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.