Phoenix evaluation backend for agent quality assessment

## Summary

Integrate Arize Phoenix as the concrete evaluation backend for Maverick's agent output evaluation framework (#17), enabling dataset-driven experiments, LLM-as-judge evaluators, and systematic quality tracking powered by OpenInference traces from #26.

## Motivation

Issue #17 defines the `AgentEvaluator` Protocol and `EvaluationResult` data model for structured agent quality assessment. What it leaves open is **where evaluation data lives and how experiments are run**. Building a custom evaluation backend from scratch would be significant effort and would miss the opportunity to leverage an existing, mature ecosystem.

[Arize Phoenix](https://github.com/Arize-ai/phoenix) (8.5K GitHub stars, Apache 2.0) provides:

- **Datasets**: Upload input/expected-output pairs for systematic testing
- **Experiments**: Run agent configurations against datasets and compare results
- **LLM-as-judge evaluators**: Define quality criteria evaluated by an LLM
- **Code-based evaluators**: Programmatic checks (format compliance, coverage metrics)
- **Human annotation**: Manual quality review workflows
- **Trace-linked evaluation**: Evaluation results attach directly to OpenInference spans
- **Local-first**: `phoenix launch` runs entirely locally, no cloud dependency

### Use cases for Maverick

1. **Regression detection**: Run the same tasks against different model versions / prompt changes and compare quality scores
2. **Backend comparison**: When #14 (multi-backend abstraction) ships, compare Claude vs. Copilot on identical tasks
3. **Prompt engineering validation**: Measure whether system prompt changes actually improve agent outputs
4. **Cost/quality tradeoffs**: Compare cheaper models (Haiku) vs. expensive ones (Opus) on quality metrics per dollar

### Dependency chain

```
#26 (OpenInference tracing) ──► This issue ◄── #17 (Evaluation framework)
│ │
└── Provides trace data ──────────────────────►│
Provides Protocol + │
data model ─────────┘
```

## Proposed Architecture

### New module structure

Extends #17's proposed `src/maverick/evaluation/` package:

```
src/maverick/
├── evaluation/
│ ├── __init__.py
│ ├── protocol.py # From #17: AgentEvaluator Protocol
│ ├── metrics.py # From #17: QualityMetric, EvaluationResult
│ ├── registry.py # From #17: Evaluator registry
│ ├── phoenix/
│ │ ├── __init__.py
│ │ ├── client.py # Phoenix client wrapper
│ │ ├── datasets.py # Dataset creation from session logs
│ │ ├── experiments.py # Experiment runner
│ │ └── evaluators.py # Phoenix-backed evaluator implementations
│ └── evaluators/
│ ├── __init__.py
│ ├── code_review.py # From #17
│ ├── implementation.py # From #17
│ └── generation.py # From #17
```

### Session log → Phoenix dataset pipeline

Maverick's existing JSONL session logs contain complete workflow execution data. This pipeline converts them into Phoenix datasets for systematic evaluation:

```python
from maverick.evaluation.phoenix.datasets import SessionLogDatasetBuilder

builder = SessionLogDatasetBuilder(phoenix_client)

# Create a dataset from one or more session logs
dataset = await builder.create_dataset(
name="fly-workflow-v2.1",
session_logs=[
Path(".maverick/logs/session-001.jsonl"),
Path(".maverick/logs/session-002.jsonl"),
],
# Extract specific step outputs as evaluation targets
step_filter=["implement", "review", "generate_pr_body"],
)
```

Each dataset row contains:
- **Input**: The step's input context (from `StepStarted` + preceding events)
- **Output**: The step's actual output (from `StepCompleted` + `AgentStreamChunk` events)
- **Metadata**: Token counts, duration, cost, model, agent name
- **Trace link**: `trace_id` from #18/#26 for linking back to full traces

### Experiment runner

```python
from maverick.evaluation.phoenix.experiments import ExperimentRunner

runner = ExperimentRunner(phoenix_client)

results = await runner.run_experiment(
name="opus-vs-sonnet-implementation",
dataset="fly-workflow-v2.1",
evaluators=[
CodeReviewEvaluator(), # From #17
ImplementationEvaluator(), # From #17
],
# Optionally re-run the agent with different config
variants={
"opus": {"model": "claude-opus-4-6"},
"sonnet": {"model": "claude-sonnet-4-5-20250929"},
},
)
```

### Phoenix-backed evaluators

Concrete implementations of #17's `AgentEvaluator` Protocol that use Phoenix's evaluation API:

```python
class PhoenixLLMJudgeEvaluator:
"""Uses Phoenix's LLM-as-judge for quality assessment."""

async def evaluate(
self,
*,
agent_result: AgentResult,
context: dict[str, Any],
expected: dict[str, Any] | None = None,
) -> EvaluationResult:
# Delegates to Phoenix evaluate API with custom rubric
...
```

### CLI integration

```bash
# Create a dataset from session logs
maverick evaluate dataset create \
--name "v2.1-baseline" \
--from-logs .maverick/logs/

# Run an experiment
maverick evaluate experiment run \
--dataset "v2.1-baseline" \
--evaluator code_review \
--evaluator implementation

# View results (opens Phoenix UI or prints summary)
maverick evaluate experiment results --name "opus-vs-sonnet"

# Ad-hoc evaluation of a single session log
maverick evaluate session .maverick/logs/session-001.jsonl
```

### Configuration

```yaml
# maverick.yaml
evaluation:
enabled: false
phoenix:
endpoint: "http://localhost:6006"
project_name: maverick-eval
default_evaluators:
- code_review
- implementation
- generation
```

## Scope

### In scope
- Phoenix client wrapper with connection management
- Session log → Phoenix dataset conversion pipeline
- Experiment runner with multi-variant support
- At least one Phoenix-backed LLM-as-judge evaluator
- `maverick evaluate` CLI subcommand group
- Configuration model for evaluation settings
- Tests with mocked Phoenix client

### Out of scope
- Phoenix server packaging/distribution (users install separately)
- Custom Phoenix UI extensions
- Automated prompt optimization (use evaluation results manually)
- CI/CD integration for quality gates (future work)
- Historical trend analysis / dashboards

### Dependencies
- #17 (agent output evaluation framework) — Protocol and data model
- #26 (OpenInference tracing) — trace data that feeds evaluation
- #18 (trace ID correlation) — links session logs to traces

## Acceptance Criteria

- [ ] Phoenix client wrapper with health check and connection management
- [ ] Session log → Phoenix dataset builder (filters by step, handles all event types)
- [ ] Experiment runner supporting multiple agent configurations
- [ ] At least one LLM-as-judge evaluator implementing `AgentEvaluator` Protocol
- [ ] `maverick evaluate` CLI subcommand with dataset/experiment/session commands
- [ ] `EvaluationConfig` Pydantic model with config file support
- [ ] Graceful degradation when Phoenix is unavailable
- [ ] Tests for dataset building, experiment execution, evaluator logic
- [ ] Documentation: setup guide with Phoenix quickstart and example workflow

## References

- [Arize Phoenix](https://github.com/Arize-ai/phoenix) (8.5K stars, Apache 2.0)
- [Phoenix evaluation docs](https://arize.com/docs/phoenix/evaluation)
- [Phoenix datasets & experiments](https://arize.com/docs/phoenix/datasets-and-experiments)
- Related: #17 (evaluation framework), #26 (OpenInference tracing), #18 (trace ID correlation), #14 (multi-backend abstraction)
- Current session logging: `src/maverick/session_journal.py`

Start by reading src/maverick/session_journal.py and the related evaluation and tracing work in issues #17 and #26. Trace how session events and CLI commands are currently structured before planning the Phoenix client, dataset builder, experiment runner, configuration, and evaluate subcommands. Done means the listed acceptance criteria are implemented with mocked-client tests and setup documentation.

Written by the indexing model from the issue text.