Add manual runtime selection and capability-aware routing

## Parent and milestone

- Parent issue: #23
- Milestone: not scheduled; implementation starts after #15.

## Problem

Multiple adapters are not useful if task creation cannot choose one safely, while automatic routing without capability and usage evidence would make outcomes unpredictable.

## Outcome

Add explicit per-task runtime selection first, then an opt-in deterministic router based on required capabilities, configured preferences, availability, privacy, and observed usage.

## Scope

- Add runtime IDs and required capabilities to task configuration.
- Expose available runtimes and reasons for ineligibility.
- Add deterministic manual, preferred-order, and capability-aware policies.
- Record the routing decision and usage observations without claiming cross-provider token equivalence.

## Non-goals

- Routing to consumer web chat.
- Circumventing provider usage limits.
- Dynamic price arbitrage without official machine-readable data.

## Acceptance criteria

- [ ] Manual selection is available before automatic routing.
- [ ] Routing is explainable, deterministic for the same state, and auditable.
- [ ] Missing capability, unavailable runtime, and exhausted configured budget produce explicit outcomes.
- [ ] Targeted and conformance tests pass.
- [ ] Architecture, adapter, and operator documentation is updated.

## Validation

- Test routing matrices, fallback order, health changes, privacy constraints, stale usage data, and deterministic replay.

## Dependencies

#28, #29, #30, and unified configuration in #14.

Start with the unified configuration work in #14 and the dependent adapter issues #28, #29, and #30. Review the targeted and conformance tests, then validate routing matrices, fallback order, health changes, privacy constraints, stale usage data, and deterministic replay. Done means the acceptance criteria pass and the architecture, adapter, and operator documentation are updated.

Written by the indexing model from the issue text.