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)

Start with the workflow JSON Schema, WORKFLOWS.md model-selection section, and the runner's _handle_run_agent entry point. Trace how workflow.agent_config.model and the Blueprint default are resolved, then inspect TaskEvents and OTEL span tests. Done means optional run_agent step models validate against the allow-list, resolve in the stated order, emit the resolved model, and are documented with tests.

Written by the indexing model from the issue text.