smite-ir: implement FundedChannelAnnouncementGenerator

[devvaansh]

Generates programs that send channel_announcement messages whose bitcoin keys and short_channel_id come from a real confirmed 2-of-2 P2WSH funding output, so they can pass the on-chain UTXO validation performed by CLN and LND.

#155 resolved the short_channel_id half of this, but nothing ever emitted the operation, and ChannelAnnouncementGenerator picks its bitcoin keys with generate_fresh, unrelated to any funding output. Deriving the funding pubkeys from the announced private keys closes the gap. No new operations are needed, since DerivePoint, CreateFundingTransaction, BroadcastTransaction, MineBlocks, and LookupShortChannelId already compose.

ChannelAnnouncementGenerator is left alone, mirroring the existing OpenChannelGenerator / FundingFlowGenerator split. CreateFundingTransaction aborts the whole program when coin selection fails, so folding the funding sequence into the existing generator would make every channel_announcement contingent on it and cost us the cheap path that always sends.

funding_satoshis and feerate_per_kw are emitted directly instead of picked, since generate_fresh(Amount) draws from the full u64 range and exceeds MAX_MONEY about 99.99% of the time, which aborts nearly every program before the announcement is built. OperationParamMutator can still widen both. FundingFlowGenerator picks those same two values and has the same exposure, which seems worth a follow-up.

Tested with unit tests covering the ordering of the funding sequence, that each announced bitcoin key is the one behind the corresponding funding pubkey, and that the generated amounts stay in range. Not yet fuzzed against the targets; I'll follow up with coverage once I've run a campaign.

Ref: #71

[NishantBansal2003]

I think we should update the existing channel announcement generator to only create, broadcast, and mine the tx, and then use that SCID only. Otherwise, there isn't much difference between the two, and we can always test all the other cases with the current set of mutators. WDYT?

Also, does it make sense to include a full gossip generator that creates a fully funded channel announcement, followed by a node announcement and then a channel update for it?

[devvaansh]

I think we should update the existing channel announcement generator to only create, broadcast, and mine the tx, and >then use that SCID only. Otherwise, there isn't much difference between the two, and we can always test all the other >cases with the current set of mutators. WDYT?

i think Keeping both generators preserves cheap bogus-SCID testing without block-mining overhead.
since in a funded-only program, the short_channel_id is structurally immutable - LookupShortChannelId has no direct parameters, and InputSwapMutator/InstructionDeleteMutator bail when no other SCID producer exists in scope.
Relying solely on GeneratorInsertionMutator to introduce SCIDs drops arbitrary and boundary SCID exploration.

Also, does it make sense to include a full gossip generator that creates a fully funded channel announcement, followed >by a node announcement and then a channel update for it?

Yes, worth doing - NodeAnnouncementGenerator and ChannelUpdateGenerator pick their signing key via pick_variable, and after a channel announcement the most recent key in scope is bitcoin_sk_2, so they almost never sign with an actual node key and the messages don't link up.