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)

Commencez par le JSON Schema du workflow, la section de sélection du modèle de WORKFLOWS.md et le point d’entrée _handle_run_agent du runner. Suivez la résolution de workflow.agent_config.model et de la valeur par défaut de Blueprint, puis examinez TaskEvents et les tests de spans OTEL. Le travail est considéré comme terminé lorsque les modèles des étapes run_agent facultatives sont validés par rapport à l’allow-list, résolus dans l’ordre indiqué, que le modèle résolu est émis et que le tout est documenté avec des tests.

Rédigé par le modèle d'indexation à partir du texte de l'issue.