Implement LLM-Generated Pipeline Intention and Architecture Summaries

# Implement LLM-Generated Pipeline Intention and Architecture Summaries

## Overview
The original specification in issue #307 requires the orchestrator model to generate intelligent summaries of pipeline intention and architecture during compilation. This feature is currently missing from the implementation.

## Missing Features

### 1. Pipeline Intention Summary
**Current State**: Not implemented
**Required**: Orchestrator model generates intention summary during compilation:
```python
pipeline = orc.compile("research_report.yaml")
print(pipeline.intention) # 3-10 sentence summary of overarching goal
```

**Specification from #307**:
> prompt the orchestrator model to summarize the *intention* and *architecture* of the pipeline:
> - intention: what's the overarching goal? use the given description(s) as a starting point, but also incorporate additional details across steps (not just from the header). generate on the order of 3--10 sentences depending on the complexity of the pipeline. for very complex pipelines, generate a higher level summary using up to 10 sentences; for simpler pipelines generate shorter and more specific summaries that are closer to 3 sentences. format as markdown and avoid conversational text. store in pipeline.intention as a string.

### 2. Pipeline Architecture Summary
**Current State**: Not implemented
**Required**: Orchestrator model generates architecture description:
```python
print(pipeline.architecture) # detailed logic description with control flow
```

**Specification from #307**:
> - architecture: how does the pipeline work? generate a detailed description of the complete logic of the pipeline. pay special attention to control flow and how the design of the pipeline supports the overall intention. use pseudocode, a numbered list, or another intuitive format as appropriate. format as markdown and avoid conversational text. store in pipeline.architecture as a string.

### 3. Architecture Validation
**Current State**: Not implemented
**Required**: Orchestrator model validates architecture matches intention:
```python
# During compilation - should raise exception if mismatch detected
pipeline = orc.compile("inconsistent_pipeline.yaml") # Should raise ValidationError
```

**Specification from #307**:
> use the orchestrator model to check whether the architecture matches the intention of the pipeline. if not, raise an exception.

## Implementation Requirements

### Compilation Integration
- [ ] Integrate orchestrator model calling during `compile()` process
- [ ] Generate intention summary from pipeline description + step details
- [ ] Generate architecture summary with control flow analysis
- [ ] Validate architecture-intention alignment
- [ ] Store summaries as `pipeline.intention` and `pipeline.architecture` properties

### Model Integration
- [ ] Use configured orchestrator model for summary generation
- [ ] Implement proper prompting strategy for consistent output format
- [ ] Handle model API errors gracefully during compilation
- [ ] Support fallback behavior when orchestrator model unavailable

### Output Format Requirements
- [ ] **Intention**: 3-10 sentences, Markdown format, non-conversational
- [ ] **Architecture**: Detailed logic with pseudocode/numbered lists, Markdown format
- [ ] **Validation**: Clear exception messages when architecture doesn't match intention

### Error Handling
- [ ] ValidationError when architecture-intention mismatch detected
- [ ] Graceful degradation when orchestrator model unavailable
- [ ] Clear error messages for model API failures
- [ ] Timeout handling for slow model responses

## Implementation Strategy

### Phase 1: Basic Summary Generation
1. Add orchestrator model integration to YAMLCompiler
2. Implement intention summary generation
3. Implement architecture summary generation
4. Store summaries in compiled pipeline object

### Phase 2: Architecture Validation
1. Implement architecture-intention alignment checking
2. Add validation exception handling
3. Comprehensive error reporting

### Phase 3: Production Hardening
1. Model API error handling and retries
2. Performance optimization for compilation speed
3. Caching strategies for repeated compilations

## Acceptance Criteria

1. **API Compatibility**: `pipeline.intention` and `pipeline.architecture` accessible after compilation
2. **Quality Output**: Summaries follow specified format requirements (Markdown, non-conversational)
3. **Validation**: Architecture-intention mismatches properly detected and reported
4. **Error Handling**: Graceful behavior when orchestrator model unavailable
5. **Performance**: Compilation time increase < 30% compared to current implementation
6. **Testing**: Real pipeline examples with actual orchestrator model calls

## Priority: Medium-High
This feature is explicitly required in the original specification and provides valuable insight into pipeline behavior for users and debugging.

## Related Issues
- Original specification: #307
- Epic implementation: #308
- Compilation system: #310

Start with the YAMLCompiler and compile() path, then review the requirements in issues #307, #308, and #310. Define how intention and architecture are generated and stored on the compiled pipeline, how alignment validation and model failures are handled, and what tests cover the acceptance criteria. Done means compilation exposes both summaries, reports mismatches clearly, and handles unavailable or slow model calls as specified.

Written by the indexing model from the issue text.