test: integrate Meshtastic MCP server into testing methodology

[eric-becker]

Problem

Floodgate's tests today exercise the gRPC ExHook surface and the zerohop/drop logic against synthetic protobuf payloads (see tests/integration/ and tests/payloads/protobuf/). They do not exercise the resulting modified packets against actual Meshtastic firmware behaviour — so issues like the traceroute-rendering bug (the Meshtastic ffff (ffff) ghost-hop issue, separate issue) are only caught by manual on-device testing.

The upstream Meshtastic firmware PR meshtastic/firmware#10194 ("Add MCP server for interacting with meshtastic devices and testing framework / TUI") introduces an MCP server plus testing framework that lets tooling drive a (real or simulated) Meshtastic device programmatically.

Proposed solution

1. Track the upstream PR; once merged, evaluate whether the MCP server can be brought up alongside the existing docker-compose.test.yaml integration stack.
2. Add a new test tier that uses the Meshtastic MCP server to:
   • Inject a packet through floodgate (zerohopped) and assert the receiving (simulated) device renders it as a single hop with the correct sender, no Meshtastic ffff (ffff) filler, and 0 dB synthetic SNR.
   • Run a traceroute through a zerohopped MQTT gateway and assert the route list matches expectations.
   • Cover drop-by-portnum cases (e.g. RANGE_TEST_APP) end-to-end against a firmware-shaped consumer rather than just verifying the ExHook response.
3. Update CONTRIBUTING.md and CLAUDE.md to document the new tier and how to run it locally.
4. If the MCP server can run headless in CI, wire it into the integration job; otherwise mark it as an opt-in local tier.

Alternatives considered

• Stay with synthetic-payload tests only — fast, but misses firmware-side rendering bugs.
• Build a custom Meshtastic device simulator just for floodgate — duplicative once upstream lands.

Refs

• Upstream PR: Add MCP server for interacting with meshtastic devices and testing framework / TUI meshtastic/firmware#10194
• Existing integration harness: scripts/run-integration.sh, docker-compose.test.yaml