smite: add query_short_channel_ids and reply_short_channel_ids_end codecs

[devvaansh]

The request/response pair for BOLT 7's short channel id query, types 261 and 262. Neither is consumed by a scenario yet; this is the codec layer for the gossip query codecs listed as a stretch goal in #71.

encoded_short_ids is kept as a Vec<u8> rather than decoded into a Vec<ShortChannelId>. Its first byte is an encoding_type selecting how the rest is encoded: 0 is an ascending array of 8-byte ids, and 1 was zlib, which the spec now says MUST NOT be used. Decoding into typed ids would mean:

• encode() returns Vec<u8> rather than Result, so it would have to pick an encoding type, which the codec has no basis for
• encoding type 1 and every unknown type could not be represented at all
• byte fidelity would be lost, so a recorded target message would no longer survive a decode/encode roundtrip, which is the reason channel_update and node_announcement carry extra
• a target that sends zlib would produce a harness error rather than a finding

Keeping the wire bytes leaves whether the encoding type is legal, the ids ascending, the set free of duplicates, or the flags one-per-id to an oracle, the same way channel_update keeps unknown flag bits and tx_abort keeps arbitrary data. query_flags carries the same encoding_type byte and gets the same treatment; its flags are variable-width bigsizes, so TlvStream::get_as_many could not parse them anyway.

The TLV stream itself is parsed rather than ignored: ordering and the even/odd rule are enforced, and query_flags has its own named field. reply_short_channel_ids_end ignores trailing bytes because BOLT 7 defines no tlv_stream for 262, same as tx_complete.

full_information is a u8 rather than a bool, since the spec defines only 0 and 1 and says nothing about the other 254 values.

262 is an even type, so Message::decode used to reject it with UnknownEvenType. Now that both messages decode, the last commit adds them to the gossip skip arm in recv_non_ping so they don't surface as UnexpectedMessage. Happy to pull that into its own PR if you'd rather keep this one to smite/.

query_channel_range and reply_channel_range will follow in a second PR. They need a channel_update_checksums wire type, and they touch the same ordered blocks in bolt.rs, so they would conflict if developed alongside this one.

[erickcestari]

LGTM! Have only some small nits.