agent: Per-step model hints in workflow YAML

## Component

Agent (Python runtime)

## Describe the feature

Allow workflow YAML steps to declare an optional `model` override so different phases of a task can use different Bedrock models without defining separate workflows.

Example (single `run_agent` step permitted today):

```yaml
steps:
- { kind: clone_repo, name: setup }
- { kind: run_agent, name: implement, model: { id: anthropic.claude-sonnet-4-6 } }
- { kind: verify_build, name: build, gate: regression_only }
```

Resolution follows [WORKFLOWS.md model selection](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/blob/main/docs/design/WORKFLOWS.md#model-selection): Blueprint allow-list bounds all choices; per-task API override remains highest unless `allow_task_override: false`.

## Use case

Model fit is task-phase-specific. Today `agent_config.model` applies workflow-wide. Per-step `model` on the lone `run_agent` step documents intent and prepares the schema for future multi-step agent graphs.

Distinct from #439 (runtime per-turn adaptive router) — this is **declarative workflow data**, not a heuristic.

## Proposed solution

1. Add optional `model: { id, allow_task_override? }` to step objects in workflow JSON Schema (`run_agent` only initially).
2. Validator: step `model.id` must be on platform/Blueprint allow-list.
3. Runner: merge step-level model over `workflow.agent_config.model` over Blueprint default in `_handle_run_agent`.
4. Telemetry: record resolved model per step on TaskEvents / OTEL spans.
5. Tests and WORKFLOWS.md update.

## Other information

- Related: #439 (per-turn router — complementary), ADR-014 / #248 workflows.

## Acknowledgements

- [ ] I may be able to implement this feature
- [x] This might be a breaking change (schema addition only — backward compatible if optional)

Empieza por el JSON Schema del workflow, la sección de selección de modelos de WORKFLOWS.md y el punto de entrada _handle_run_agent del runner. Traza cómo se resuelven workflow.agent_config.model y el valor predeterminado de Blueprint y, después, inspecciona TaskEvents y las pruebas de spans de OTEL. Se considera terminado cuando los modelos de los pasos run_agent opcionales se validan contra la allow-list, se resuelven en el orden indicado, emiten el modelo resuelto y quedan documentados con pruebas.

Escrito por el modelo de indexación a partir del texto del issue.