fix(mesh): a peer's claim about its own trustworthiness is not evidence (#1253)

[dc0sk]

Closes #1253.

The defect

wire_trust_level mapped a PeerQueryResponse's trust_state = 0x00 to TrustLevel::Verified and
wrote it straight into the peer cache that trust_filter_allows consults:

0x00 => TrustLevel::Verified,

That byte is the responder's claim about itself, carried in an envelope this node does not
authenticate before importing. So a station could assert its own trustworthiness and thereby satisfy
the operator's strict relay policy — the policy that exists precisely to decide whose third-party
traffic this station retransmits. The operator-configured policy was being enforced against a
peer-supplied value.

Found by a verifier while refuting a neighbouring audit finding about unknown-code catch-alls. The
catch-all was harmless (Reduced is the most restrictive level the enum has); this was a different
byte, in the opposite direction.

The fix is a deletion, not a correction

There is no honest mapping from a self-assertion to a trust level, because this crate has no local
trust store to resolve the claim against — verified: no TrustStore reference anywhere in
crates/openpulse-mesh/src/, and no such dependency in its Cargo.toml. A function whose only
correct answer is one constant is not a mapping, so wire_trust_level is deleted rather than
corrected, and every peer-asserted state imports as Unknown.

The consequence, and why the node still starts

With every import Unknown, TrustedOnly can never be satisfied — so strict relays nothing.

The node warns loudly and still runs rather than refusing to start. That follows the maintainer's
standing ruling: untrusted is this project's default for synchronized operation including relay and
mesh, and operators restrict upward by accepting trust levels, not by the protocol refusing to
run. The operator asked for a restriction this crate cannot implement; the honest response is to run,
relay nothing, and say why — naming the fix (balanced, or the full daemon, which resolves trust
against the signed handshake).

Tests — unit tests, deliberately

The properties are about peer_cache and trust_filter_allows, both private. My first draft was an
integration test that added peer_trust_level and relay_allowed_for to the public API to reach
them — which is the "public API for an instrument" shape this project bans and #1271 is currently
about. That draft was deleted rather than shipped.

Three tests in mod peer_asserted_trust_tests, driving the real receive path (step →
handle_peer_query_response) with a frame injected over a loopback backend:

• every claimed state — 0x00, 0x01, 0x02, 0x03, 0xFF — imports as Unknown, with a
  positive control first that the import path ran at all, so the assertion cannot pass because
  nothing was imported;
• a self-vouching peer does not satisfy TrustedOnly;
• strict refuses even a peer we genuinely heard, with a balanced control so it cannot pass in
  a build where relaying is broken outright.

All three fail against the restored defect, each on its own assertion
(trust_state = 0x00 must import as Unknown; a peer's claim about itself is not evidence); restored
by sha256sum.

Fixture note: the response carries an empty descriptor_signature, and that is part of the
point — the import path never verifies it, which is exactly why the trust_state beside it cannot be
treated as evidence. (A 64-byte one also pushes the envelope past one 255-byte frame.)

Gate

suites=324 tests_passed=2456 tests_failed=0
GATE: PASS c5650a694874f0c74efc4f6b341b043c250c6468 clean 20260905T080313Z

Docs

architecture.md's TrustFilter table now says the filter is only as good as where the cached level
came from; openpulse-manual.md warns that strict relays nothing in this binary and names the
alternatives.

Compounds with #1251 — same binary, and since that change openpulse-mesh has no route to a sound
card at all, which bounds the on-air exposure but not the correctness.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6