fix(router): cap AnnounceFile tx_ids fan-out

[0g-peterzhb]

Closes #423

on_announce_file expands one gossip message into msg.tx_ids.len() separate consumers. tx_ids is an uncapped Vec<TxID> and nothing on the receive path checked its length — the only bound was GOSSIP_MAX_SIZE_POST_MERGE = 10 MB, applied to the decompressed size, so a small snappy payload can carry ~262k TxIDs.

The sharp edge: quadratic memory in the file location cache

// node/file_location_cache/src/file_location_cache.rs:306-309
let mut cache = self.cache.lock();
for tx_id in announcement.tx_ids.iter() {
    cache.insert(*tx_id, announcement.clone());   // deep copy, once per tx_id
}

AnnounceFile.tx_ids is a plain Vec with no Arc, so each clone deep-copies the whole list. N clones each holding N entries is O(N²) memory from a single message. At 40 bytes per TxID:

tx_ids	allocated
1,000	~40 MB
10,000	~4 GB
262,000	~2.7 TB

max_entries_total = 1_000_000 does not help: the loop inserts N distinct tx_ids, so total_announcements == N after one message, well under the cap — no eviction fires. The limit counts announcements, not bytes, and each announcement here is up to 10 MB.

One signed message within the protocol's own size limit therefore OOMs the node, with no sustained bandwidth required.

Secondary: sync channel fan-out

Each tx_id also becomes its own SyncMessage::AnnounceFileGossip on an unbounded channel, and PubsubRateLimiter meters messages rather than their contents. Milder than it looks — with the default sync_file_on_announcement_enabled = false the drain early-returns after a hashmap lookup, so the queue keeps up under one peer. It matters mainly when that setting is on, where each message costs an inline get_tx_status RocksDB read.

Change

Reject anything above MAX_ANNOUNCE_FILE_TX_IDS (256) and penalise the sender.

This is a const, not a config field. Rejecting a gossip message also stops its propagation and scores the sender down, so nodes disagreeing on the threshold would penalise honest peers and make propagation depend on which node received the message. GOSSIP_MAX_SIZE_POST_MERGE — the only other bound on this same field — is a plain const for the same reason. Changing it means a coordinated network upgrade.

256 leaves a 25x margin over batcher_file_capacity = 10 in the shipped configs, and caps the cache cost at roughly 2.6 MB per message.

A deployment batching above the limit is a misconfiguration, not something peers should absorb by loosening their own validation, so batcher_file_capacity > MAX_ANNOUNCE_FILE_TX_IDS now fails at startup — once, locally, with a clear message — instead of silently earning peer penalties network-wide.

Scope

This bounds the blast radius; it does not fix the quadratic clone itself. That needs the cache to share one Arc<SignedAnnounceFile> across entries rather than cloning per tx_id — filed as #437.

Verification

cargo test -p router: 21 passed, including test_on_pubsub_announce_file_oversized_tx_ids, which asserts Reject and that nothing reached the sync layer. cargo fmt --all -- --check and cargo clippy -- -D warnings both clean.

🤖 Generated with Claude Code

---

This change is