#301 Per-method telemetry events for workflow runs

Problem

Today, swamp workflow run <name> emits exactly one telemetry event for the entire CLI invocation. The event captures command: "workflow", subcommand: "run", the workflow name in args, total duration, invocation context, and a single aggregate result.status.

This means we lose all per-step/per-method observability for workflows:

• Which model methods ran inside the workflow, and how many.
• Per-method duration, so we can't see which steps dominated wall-clock time.
• Which specific step failed when a workflow errors — only the rolled-up status survives.
• Per-driver / per-model-type usage signals for workflows specifically.

The workflow engine already emits rich internal MethodExecutionEvent and WorkflowExecutionEvent events for the UI/renderers, but DefaultMethodExecutionService does not record telemetry, and the CLI bootstrap (src/cli/mod.ts:1143,1225) only fires recordSuccess() / recordError() once after the whole command completes.

Proposed Solution

Emit child telemetry records for each model method invocation that happens inside a workflow run, parented to the outer CLI invocation:

• New event type (e.g. workflow_method_invocation) emitted from the workflow execution path.
• Fields: parent_invocation_id, workflow name, job name, step name, model type, method name, driver, duration, status, error category on failure.
• Reuse the existing internal MethodExecutionEvent / WorkflowExecutionEvent stream so we don't add a second instrumentation point — bridge them into the TelemetryService instead.
• Apply only to workflow run (and any future workflow execution commands); keep the single-event shape for non-workflow CLI invocations.

Alternatives Considered

1. Leave as-is. Cheapest, but workflow observability stays blind past the outer envelope.
2. Single rolled-up event with embedded step summaries. One event per invocation with a steps[] array. Simpler ingest, but harder to query/aggregate across workflows and bloats individual rows.
3. Emit child events only on failure. Cuts volume, but loses the duration/usage signal on the happy path, which is the more interesting analytics case.

Preference is option (1) in the proposed solution — full per-method child events parented by invocation_id — because it makes both success and failure paths queryable with the same shape.

Context

• CLI telemetry bootstrap: src/cli/mod.ts:1143,1225
• Per-invocation context fields landed recently in 3d787176 (agent harness + TTY).
• Workflow execution emits MethodExecutionEvent / WorkflowExecutionEvent for the renderer; these are the natural source to bridge into telemetry.