Trace ID propagation and failure deeplinks

## Problem

Acceptance tests against a deployed system fail in ways that are best diagnosed in the backend's trace data — Jaeger, Honeycomb, Datadog, Tempo. Today, when a test fails, the operator has no way to find the corresponding trace short of guessing time windows and searching logs. The connection between "this test failed" and "here is exactly which downstream span returned 500" doesn't exist.

## Proposed solution

rigtest mints a `traceparent` value per test attempt and propagates it automatically: the built-in HTTP client injects it as a header on every request; the SSH client exports it as an environment variable on every command. On failure, the reporter prints a clickable deeplink using a configurable template:

```
FAIL homepage_returns_200
trace: 4bf92f3577b34da6a3ce929d0e0e4736
jaeger: https://jaeger.staging/trace/4bf92f3577b34da6a3ce929d0e0e4736
```

```rust
let resp = ctx.client().await?.get(url).send().await?; // traceparent injected automatically
let trace_id = ctx.trace_id(); // accessible if the test wants to log it
```

## Alternatives considered

Users can mint and inject trace IDs by hand in every test, but it requires discipline, error-prone wiring, and doesn't get surfaced in the failure output. Other test harnesses leave this entirely to the user.

## Additional context

Trace ID is generated coordinator-side and passed into each subprocess via `RIGTEST_TRACE_ID` (same channel as global state). The W3C `traceparent` header format is the right wire format. The deeplink template needs a config home; the natural place is per-environment configuration (different envs typically point at different observability backends), but the core feature — generating the trace ID, injecting it on the wire, and surfacing it in failure output — can ship independently and degrade gracefully to "no deeplink, just the raw trace ID" until that config surface exists.