Wipe empty entries from actions_blocking_raa_monitor_updates

[TheBlueMatt]

In a very specific case, forgetting to do so can lead to a debug assertion failure when we see a double-claim of an HTLC (see the included test).

Found by @joostjager's work on growing the chanmon_consistency fuzzer.

[ldk-reviews-bot]

I've assigned @valentinewallace as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[coderabbitai]

Caution

Review failed

An error occurred during the review process. Please try again later.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ldk-claude-review-bot]

I've reviewed the entire PR diff, examined all sites that modify actions_blocking_raa_monitor_updates, and cross-referenced with my prior review findings.

Review Summary

No new issues found.

The fix correctly applies the Entry API + remove-if-empty pattern at both sites:

1. channelmanager.rs:9821-9838 — FreeDuplicateClaimImmediately handler in claim_funds_internal
2. channelmanager.rs:15257-15264 — handle_monitor_update_release

My prior review's cross-cutting concern (that the FreeDuplicateClaimImmediately handler at ~9821 had the same stale-entry bug) has been addressed — that site now uses the same Entry API + remove-if-empty cleanup.

I verified all other sites that touch actions_blocking_raa_monitor_updates — the remaining locations are either insertions (push), the PaymentClaimed handler (which already had the correct cleanup at line 10283), or the clear() during init replay (line 15232). No remaining sites perform retain without empty-entry cleanup.

The test covers the specific scenario (offchain claim followed by on-chain duplicate claim) and verifies no debug_assert panic occurs.

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 87.07%. Comparing base (db42ad6) to head (f14b4b2).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	92.30%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4537      +/-   ##
==========================================
- Coverage   87.10%   87.07%   -0.04%     
==========================================
  Files         163      163              
  Lines      108765   108809      +44     
  Branches   108765   108809      +44     
==========================================
+ Hits        94743    94747       +4     
- Misses      11535    11571      +36     
- Partials     2487     2491       +4     

Flag	Coverage Δ
fuzzing	40.16% <46.15%> (-0.04%)	⬇️
tests	86.18% <92.30%> (-0.02%)	⬇️

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.