Bloom module test coverage, benchmarks, and design doc corrections

Testing:
- Add 14 bloom module tests (39 total): from_bytes error paths,
  from_slice round-trip, insert_bytes/contains_bytes, estimated_count
  saturation, Default/Debug traits, mark_changed_peers cascade
  prevention (4 scenarios), remove_peer_state, record_sent_filter,
  leaf_dependents accessor.

Benchmarks:
- Add criterion benchmark suite for bloom filter hot-path operations:
  insert, contains, merge, from_bytes, fill_ratio, estimated_count,
  equality, compute_outgoing_filter, mark_changed_peers, base_filter.
  Parameterized over realistic occupancy levels and peer counts.

Design doc corrections:
- Fix visited bloom filter hash_count in gossip protocol doc (7→5,
  matching code for 256-byte filter occupancy).
- Correct LookupResponse proof signature scope in fips-routing.md
  and fips-gossip-protocol.md: proof covers (request_id || target)
  only — coords excluded to survive tree reconvergence during lookup
  RTT.

docs/design/fips-gossip-protocol.md

@@ -386,8 +386,10 @@ LookupResponse {
 **target_coords**: The target's current tree coordinates. This is the primary
 payload — cached by the originator to enable routing to the target.
 
-**proof**: Target's signature over `(request_id || target || target_coords)`.
-Prevents malicious nodes from claiming reachability and blackholing traffic.
+**proof**: Target's signature over `(request_id || target)`. Prevents
+malicious nodes from claiming reachability and blackholing traffic.
+Coordinates are excluded from the proof to avoid invalidation during
+tree reconvergence (see [fips-routing.md](fips-routing.md) §2.4).
 
 ### 5.3 Routing
 
@@ -680,7 +682,7 @@ PLAINTEXT BYTES:
 40                               ← ttl = 64
 04 00                            ← origin_coords_count = 4
 [16 bytes] × 4                   ← origin's ancestry (64 bytes)
-07                               ← visited hash_count = 7
+05                               ← visited hash_count = 5
 [256 bytes visited bloom]        ← nodes that have seen this request
 
 Total: 1 + 8 + 16 + 16 + 1 + 2 + 64 + 1 + 256 = 365 bytes
@@ -708,8 +710,8 @@ Returns target's coordinates to the requester.
 │  │  ...   │ proof            │ 64 bytes  │ Target's signature            │  │
 │  └────────┴──────────────────┴───────────┴───────────────────────────────┘  │
 │                                                                             │
-│  Proof signature covers: (request_id || target || target_coords)            │
-│  Prevents malicious nodes from claiming reachability for any target.        │
+│  Proof signature covers: (request_id || target)                             │
+│  Coords excluded to survive tree reconvergence during lookup RTT.          │
 │                                                                             │
 └─────────────────────────────────────────────────────────────────────────────┘
 ```

docs/design/fips-routing.md

@@ -301,9 +301,17 @@ Each router forwards toward the origin using tree distance.
 ### Security
 
 The target signs the LookupResponse with a proof covering
-`(request_id || target || target_coords)`. Without this signature, a malicious
-node could claim reachability for any target and blackhole traffic. The
-signature proves the target authorized the route.
+`(request_id || target)`. Without this signature, a malicious node could
+claim reachability for any target and blackhole traffic. The signature
+proves the target authorized the route.
+
+Note: `target_coords` are intentionally excluded from the proof. Binding
+coordinates would invalidate the signature whenever the spanning tree
+reconverges (parent switch, root change), causing valid responses to be
+rejected if tree topology shifts during the lookup RTT. Since coordinates
+are ephemeral routing hints and data integrity is protected by the
+session layer, coordinate tampering by a transit node only causes routing
+inefficiency, not a security breach.
 
 ### Caching