[codex] fix gossip rate limit bounds

[jjyr]

Summary

• reject new inbound channel-update limiter keys when tracked keys are full, after pruning idle keys
• count inbound limiter drops as PolicyRejectedMessage so sustained abuse reaches the gossip ban path
• add per-peer and global queued-byte budgets for delayed outbound gossip payloads

Root Cause

The inbound limiter was keyed by (peer, channel_outpoint, is_node1), but remote peers control channel_outpoint. When the tracked-key cap was reached, the limiter evicted an older key and admitted the new one, so unique bogus outpoints could keep feeding pending gossip work.

The delayed outbound queue was capped by item count only. Large delayed GetBroadcastMessagesResult and QueryBroadcastMessagesResult payloads could still accumulate with unclear memory bounds.

Validation

• cargo nextest run -p fnn --features rocksdb -E 'test(test_channel_update_limiter_rejects_new_keys_when_full) | test(test_delayed_outbound_queue_rejects_peer_byte_budget_overflow) | test(test_delayed_outbound_queue_rejects_global_byte_budget_overflow) | test(test_rate_limited_channel_update_from_no_channel_peer_triggers_disconnect_and_temp_ban)'
• cargo nextest run -p fnn --features rocksdb -E 'test(test_channel_update_limiter_prunes_idle_keys_before_accepting_new_key) | test(gossip_policy)'
• cargo fmt --all -- --check
• CARGO_BUILD_JOBS=1 cargo clippy -p fnn --features rocksdb --lib -- -D warnings