observability: carry trace context into workflow node jobs #1047

Follow-up to #854.

Workflow node jobs lose the submitter's trace context. crates/flexiq-workflows/src/lifecycle.rs builds every node job's metadata from build_metadata_json(run_id, node) — the routing blob {"workflow_run_id", "workflow_node_name"} — and the submit request has no metadata of its own. So a traceparent present where the workflow is submitted never reaches any step, and every step's execute span starts a new trace.

#854 pins the carrier convention: traceparent / tracestate as top-level keys of the job's metadata JSON object, merged, never overwriting. This issue extends it to workflows:

1. workflow submit accepts a trace carrier (the three SDK shells, and contracts/proto for the gRPC workflow RPCs)
2. the carrier is stored on the workflow run and merged into each node job's metadata beside the routing keys — including successors released later and compensation jobs
3. the routing keys win on collision; the carrier never displaces them
4. a test that a step's execute span shares the submitter's trace id, and a polyglot case if the shells allow it

Open question: should every node be a child of the submit span (flat), or of its predecessor's execute span (chained)? Flat is simpler and matches how fan-out already behaves for pub/sub.