GossipSub: setup/configuration review follow-ups across Filecoin implementations

## Context

ProbeLab completed a GossipSub setup and configuration review of the Filecoin network: https://www.notion.so/probelab/M3-GossipSub-setup-and-configuration-review-32deaf461d4780439f15c3c4c7d7655c. In the 2026-05-12 Filecoin implementer sync, we agreed to create this top-level tracking issue for coordination. Each implementation team should create its own sub-area tracking issues in the relevant repo(s), then link them here.

The goal is to make sure each finding is reviewed by each affected implementation, while keeping cross-implementation coordination visible in one place.

## Sub-area tracking matrix

### 1.1 PeerExchange only enabled for bootnodes

**TL;DR:** PeerExchange is currently only enabled for bootnodes, which limits GossipSub-based peer discovery. We should evaluate whether each implementation should enable PeerExchange more broadly, while ensuring only appropriate public/reachable peer information is shared.

- [ ] Lotus: TBD
- [ ] Venus: TBD

### 1.2 PeerExchange not fully supported in rust-libp2p

**TL;DR:** Forest cannot fully benefit from GossipSub PeerExchange today because rust-libp2p lacks complete `SignedPeerRecord` support. We need to track what is required upstream and whether Forest needs interim handling.

- [ ] Forest: TBD
- [ ] rust-libp2p upstream: TBD

### 2.1 Global flood publishing

**TL;DR:** Flood publishing is enabled globally in the Go GossipSub configuration, which may significantly increase publisher-side bandwidth, especially with F3 traffic. We should validate the bandwidth and propagation impact, then decide whether to keep, disable, limit, or make this behavior topic-specific.

- [ ] Lotus: TBD
- [ ] Venus: TBD
- [ ] Forest: TBD

### 2.2 Peer ID exposure / `WithNoAuthor`

**TL;DR:** Messages currently include the originating peer ID, which may make SP/network identity correlation easier. We should evaluate the privacy benefit of enabling `WithNoAuthor` against the loss of observability and network-health metrics.

- [ ] Lotus: TBD
- [ ] Venus: TBD
- [ ] Forest: TBD

### 3.1 GossipSub validation queue size

**TL;DR:** The validation queue size may be too small during F3 or high-throughput message spikes, which can cause dropped messages and consensus delays. We should review defaults, monitor rejection metrics, and consider increasing the default, e.g. to 512, where appropriate.

- [ ] Lotus: TBD
- [ ] Venus: TBD
- [ ] Forest: TBD