fix(error)!: hold relay-supplied text as SafeText, bump dig-nat to 0.15

[MichaelTaylor3d]

Closes DIG-Network/dig_ecosystem#1883. Part of the dig-nat 0.15 release-first cascade (DIG-Network/dig_ecosystem#1674 / #1675).

The defect, and where it actually was

The ticket named five GossipError variants as String. Three of them are not: PeerNotConnected, PeerBanned and DuplicateConnection carry a PeerId, which is a chia_protocol::Bytes32 — a fixed 32 bytes rendered as hex. A peer cannot put text of its choosing there, so no forged peer id containing a newline exists to inject and those three are already unrepresentable. They are left as PeerId on purpose: widening them to a text type would invite a future caller to interpolate a formatted string into a field that currently cannot hold one.

The two String variants were real, and the type change surfaced a live instance the ticket had not found:

• nat/discovery.rs — RelayMessage::Error { code, message } interpolated message raw. That field is a String deserialized straight out of an explicitly untrusted relay's JSON, so a hostile relay chose its bytes freely. Proven live over a real loopback WebSocket before the fix:

  "relay error: relay error 7: denied\n2026-07-31T00:00:00Z ERROR peer 0000 is trusted\u{202e}\0"
  

• relay/relay_client.rs — handle_register_ack formatted a relay-supplied RegisterAck message the same way.

The fix

The variants whose text comes from a remote party (RelayError, ConnectionFiltered, NatError) hold dig_nat::SafeText, new in dig-nat 0.15.0. Its only doors are from_untrusted (escapes control + bidi characters, bounds the length) and from_static(&'static str), which a runtime String cannot pass through — so raw peer text becomes unrepresentable rather than guarded. That is the point: this defect was reopened once per variant by callers individually forgetting a convention, so a sanitiser you must remember to call is the wrong shape of fix.

SafeText's Debug renders like its Display, which matters here because several call sites use {:?} and a fix wired only to Display would regress them silently. Relay failures in nat::discovery now funnel through one relay_failure helper, so there is a single place to read to know no relay-chosen byte reaches a rendered error.

IoError / InvalidConfig / AddressManagerStore / IntroducerError keep String — their text comes from the OS, the local config, or this crate's own literals. Recorded at the enum with the reasoning, so the next reader does not have to re-derive which variants are in the class.

How it was verified

tests/sec_1883_peer_text_tests.rs (3 tests, new):

1. Real wire, and a placement discriminator. A hostile message carrying a real newline, an RLO bidi override (category Cf, which char::is_control misses) and a NUL travels a real loopback WebSocket relay speaking the RLY-005 wire. The assertion is on the error value the moment relay_get_peers returns it, before anything logs it — so a fix applied at a logging site rather than at the wire boundary leaves that value dirty and fails.
2. Every converted variant, not just the one call site that was broken.
3. The PeerId variants, pinning why they stay a fixed-width id.

Every assertion checks Display and Debug. Every test carries a control so the fix cannot be satisfied by dropping detail: the error must still name the subsystem, carry the relay's status code, and show the escaped reason. Both directions were confirmed rather than assumed:

• Red for the right reason — pre-fix, the real-wire test failed on the raw newline quoted above.
• The controls are load-bearing — replacing the sanitising helper with one that discards the detail (SafeText::from_static("relay query failed")) fails the control (the error must still carry the relay's status code), even though it satisfies every newline assertion.

Gates: cargo fmt --check clean, cargo clippy --all-targets --locked -- -D warnings clean, cargo test --locked green across the suite.

Pre-existing failures, NOT from this change (baseline-verified): tests/con_1691_reconnect_tests.rs fails 4 of 5 on a pristine origin/main worktree as well — peer-map newest-wins supersede semantics, untouched here. Separately, the tracked Cargo.lock on origin/main records dig-gossip 0.17.19 while Cargo.toml says 0.17.21, so cargo test --locked fails on main outright; this branch's lock is re-resolved and correct. Both are being reported for their own tickets.

Blast radius checked

Per the standing override, blast radius via ripgrep + a direct read of every construction and match site rather than gitnexus. GossipError::{RelayError,ConnectionFiltered,NatError} has 30 references across src/error.rs, src/nat/discovery.rs, src/relay/relay_client.rs, src/service/gossip_handle.rs and 5 test files; the compiler enumerated all 14 production/test breakages after the type change and each was migrated (.as_str() at match sites that bound the payload). PeerId was traced to chia_protocol::Bytes32 to establish that the other three variants needed no change. Risk: breaking for consumers — the payload type changes and the dig-nat re-pin rotates the identity of the dig-nat types re-exported from src/nat, hence the MINOR on 0.x.

Dependency + version

dig-nat = "0.14" → "0.15". The tracked lock resolves dig-nat 0.15.0 and dig-tls 0.3.0 from registry+https://github.com/rust-lang/crates.io-index, one copy of each. The pre-existing [patch.crates-io] in this manifest covers only the vendored chia-protocol / chia-sdk-client / native-tls; it does not touch the cascade crates, and it was not modified here.

0.17.21 → 0.18.0 (MINOR = breaking on 0.x): the variant payload types and the re-exported dig-nat type identities are both public-API changes.

Docs kept coherent in the same unit

docs/resources/SPEC.md §4 and docs/requirements/domains/crate_api/specs/API-004.md both declared RelayError(String) normatively, including an acceptance checkbox asserting it "contains a String". Both now state SafeText with the reason, and the API-004 variant table and its test_relay_error_display row are updated to match.

Consumers must pin

dig-gossip is not on crates.io (DIG-Network/dig_ecosystem#900 / #1872), so this version bump publishes nothing — consumers take it by git rev. A consumer moving to this commit must simultaneously be on dig-nat 0.15, since this crate re-exports dig-nat types from src/nat and a second dig-nat in the tree is now an E0308. Note that a git-rev consumer does not inherit this manifest's [patch.crates-io].