Chainsaw integration test: tunnel stands up and flows traffic

[ecv]

Summary

Add a Chainsaw integration test that stands up an iroh tunnel end-to-end and proves real traffic flows through it (client → iroh-gateway → relay → advertised backend). This is deliberately scoped as an integration test, not a smoke test: it exercises the full multi-component path (relay + gateway + an advertising endpoint + a backend workload) and asserts payload delivery, not just "pods are up."

Motivation

The iroh 1.0.2 upgrade (#168) shipped a new relay (n0computer/iroh-relay:v1.0.2) and gateway (iroh-gateway:v0.1.0). We validated the rollout by pod health and relay metrics (got_ping/sent_pong incrementing), but nothing in CI proves an actual tunnel carries payload after a version bump. The 0.97 → 1.0 boundary crossed relay wire-protocol and gateway API changes; a bump that keeps pods green but silently breaks tunnel data flow would ship undetected. This test closes that gap.

Acceptance Criteria

• A Chainsaw test proves a tunnel stands up (the tunnel/Connector resource reaches Accepted + Ready, and the gateway registers a relay path to the advertised endpoint).
• The same test proves the tunnel flows traffic: a request driven through the gateway to an advertised backend returns the backend's response body (e.g. HTTP 200 with expected payload), not just a connection.
• The test fails loudly if either the tunnel fails to establish or establishes but carries no payload.
• Runs against a local cluster in the NSO Chainsaw harness; self-contained setup and teardown (no leaked endpoints/workloads).

Proposed shape

1. Backend: apply a trivial HTTP echo/hello backend workload in-cluster.
2. Advertising listener (the crux — see below): run an iroh endpoint that advertises a stable endpoint-id and proxies to the backend.
3. Assert establishment: tunnel/Connector → Accepted + Ready; optionally scrape gateway :9090 for a relay path / opened connection to the endpoint.
4. Drive traffic: a script step issues a request through the gateway with the datum tunnel headers — x-iroh-endpoint-id, x-datum-target-host, x-datum-target-port — and asserts the backend response body.
5. Teardown: delete workload + listener + tunnel resources; assert cleanup.

Known crux / dependency

The one non-trivial piece is step 2: an in-cluster iroh listener fixture that advertises a stable endpoint-id for the gateway to dial. This is datum-cloud/app / n0des-side code, not a plain manifest. Options:

• Build a minimal "echo listener" test image running an iroh endpoint (seed its ticket/endpoint-id into the request headers).
• Reuse an existing advertised endpoint if the harness can provision one.

Scope / ownership

Belongs here in NSO, not datum-cloud/infra: NSO owns the Connector/tunnel contract and runs Chainsaw against local clusters, whereas infra's Chainsaw scope is deployment-validation only. Test domains use datumchainsaw.art per the shared Chainsaw convention.

Notes

• Tracks the open Step 4 verification item in Upgrade iroh to 1.0.2 across app, iroh-gateway, and infra #168 (end-to-end tunnel connectivity smoke test) — this issue supersedes that line with a proper integration test.
• Should run on every relay/gateway image bump so future iroh upgrades are gated on real tunnel traffic, not pod health alone.

[ecv]

Flagging as the tunnel-path coverage gap now that the prod-fidelity edge e2e suite is live in CI (#275/#276): the connector/iroh data path has no regression guard there. Acceptance in this issue is already well-specified; the remaining prerequisite is env-side — task test-infra:up (Taskfile.test-infra.yml) must stand up the iroh relay + gateway + an advertising endpoint so the scenario's dependencies are provisioned by the env (per the e2e-authoring contract), not assumed. Relates to #167 (routing-not-live-until-heartbeat) and #168 (iroh 1.0.2 bump this test was meant to cover).