refactor(workflow): per-step OTEL spans; delete CallToolInternal StartToolSpan

[QuentinBisson]

Why

CallToolInternal in internal/aggregator/server.go was opening a tool.<name> span via instrument.StartToolSpan for every internal dispatch. Two problems:

1. Duplicate span on the MCP-wire path — mcp-go's tool-handler middleware already opens an identical tool.<name> span, so a regular tools/call over the wire produced two same-named child spans.
2. Wrong layer on the workflow path — the workflow executor is the logical action ("running step X"), but the span lived in the aggregator dispatch function. A span at that layer doesn't carry workflow context.

What

• New internal/workflow/tracing.go::startStepSpan opens a workflow.step span per executed step (and per step-condition tool call). Attributes: workflow.name, workflow.step.id, mcp.tool.name. Span outcome is recorded from the tool result (IsError) and any handler error.
• internal/workflow/executor.go wraps both CallToolInternal sites (condition + step) in the new helper.
• instrument.StartToolSpan and its tests are deleted. The unit-level TestMetrics_HistogramExemplarAttachesTraceID that relied on StartToolSpan is also dropped — the production wiring is covered end-to-end by TestMCPServerOptions_HistogramExemplarAttachesToolHandlerSpan (added in refactor(aggregator): adopt mcp-go native OTEL tracing hooks #684). instrument.TracerName and instrument.AttrToolName stay shared.
• CallToolInternal becomes a transparent dispatch function with no span of its own. Direct API callers that want span granularity open one in their own layer.

Trace shape after this PR

workflow execution (caller's span, if any)
  └─ workflow.step (workflow.name=…, step.id=…, mcp.tool.name=…)   ← new
       └─ mcp client SendRequest "mcp.tools/call" (kind=Client)     ← from #685

For the MCP-wire tools/call path, the duplicate tool.<name> child span goes away — mcp-go's own middleware (adopted in #684) is the only owner of that span now.

Review follow-ups

• TestStartStepSpan table-drives the three outcome branches (err / IsError / ok) and asserts workflow.name, workflow.step.id, and mcp.tool.name land on the span. Captured via tracetest.InMemoryExporter.
• Workflow tracer scope folded into the shared instrument.TracerName (github.com/giantswarm/muster) — span name and workflow.* attributes already encode the emitter, so a workflow-local scope was redundant.
• Narrative comment in executor.go stripped (the doc on startStepSpan carries the present invariant).

Stack

This PR is now stacked on #685. Land order: #685 (server + client tracing, includes the TracerName rename) → #696 (this PR).

Validation

• go test ./... clean (every package).
• make lint clean (no new issues in changed files).
• 121/121 behavioural scenarios pass via ./muster test --parallel 50 --base-port 30000.

[QuentinBisson]

Light review (DDD / SOLID / YAGNI / DRY / don't-reinvent / tests).

Blocking — coverage regression

• No test for startStepSpan (internal/workflow/tracing.go). You correctly deleted TestStartToolSpan, but didn't replace it. The new helper has three distinct outcome branches (err, IsError, ok) and three required attributes (workflow.name, workflow.step.id, mcp.tool.name) — exactly the table-driven test shape the deleted test had. This is a real coverage regression on a span the user-facing trace explicitly relies on.

Non-blocking

• internal/workflow/tracing.go imports internal/aggregator/instrument for two constants. TracerName = "github.com/giantswarm/muster/internal/aggregator" — that's the wrong scope for spans emitted from internal/workflow. Use a workflow-local tracer name ("github.com/giantswarm/muster/internal/workflow") so trace consumers can filter by emitting package. Keep AttrToolName shared — it's a semantic key, not a scope.

Suggestion

• The narrative comment inside executor.go ("wrapped in a workflow.step span so the trace shows the workflow → step → backend hierarchy") is exactly the historical/roadmap commentary your CLAUDE.md says to strip — it explains the change, not a present invariant. The doc on startStepSpan already covers what the span does.

OAuth test-constant churn from the stack still bleeds in.