plugin: Add FORGET_CHANNEL to stuck HSM types

[cdecker]

Nodes running in bgsync mode (no signer attached) deadlock when a closed channel's onchaind finishes and lightningd's delete_channel() issues a synchronous WIRE_HSMD_FORGET_CHANNEL (msgtype 34). The StagingHsmServer only answers the canned startup messages, so the request sits in the stager forever and blocks lightningd's main loop. Because type 34 was not in stuck_request_types(), the node never reported itself stuck: update_state called getinfo on the blocked lightningd (which hangs, no timeout), stalling the 10s state poll just before blockheight == headheight would have triggered the BlockSync self-preempt. No stuck webhook fired and the 60s stuck-grace kill never engaged, so the session idled until the 1h session wall.

Prod numbers (EU bgsync, Loki 2026-10-12): ~95% of the ~2,029 cap-hit sessions/day were already-caught-up nodes stuck this way; 1,936 "onchaind complete, forgetting peer" events/day, repeating on every visit to the same nodes because the forget never commits before the session dies.

The fix mirrors 30325ff (type 18): add 34 to the sticky list, plus a unit test asserting a queued type-34 request makes the stage report stuck (and that a non-sticky type such as 27/DERIVE_SECRET does not). With the type sticky, update_state skips the hanging getinfo, the stuck webhook (NotifyStuck) summons the signer, and the session is killed after ~60s instead of ~3,540s; the forget then commits for good in the next user session with an attached signer.

Known residual race (not addressed here): a getinfo already in flight when the type-34 request arrives still hangs the state poll; an RPC timeout watchdog in update_state would be a possible follow-up.

cargo test -p gl-plugin: 34 passed, 0 failed.

🤖 Generated with Claude Code