[Feat] Add OpenAutoGLM Provider for Mobile Device Automation

## 🚀 Feature Request: OpenAutoGLM Provider Integration

### Summary
Add support for [Open-AutoGLM](https://github.com/zai-org/Open-AutoGLM) as a new provider to enable mobile device automation capabilities within the CLI Agent Orchestrator (CAO) system.

### 📋 Problem Statement
Currently, CAO supports various CLI-based providers (claude_code, codex, q_cli, kiro_cli) but lacks mobile device automation capabilities. Open-AutoGLM provides sophisticated Android device control through natural language instructions, which would be a valuable addition to the CAO ecosystem.

### 🎯 Solution Overview
Implement a new `OpenAutoGLMProvider` that integrates Open-AutoGLM's mobile automation capabilities with CAO's orchestration system.

### 🔧 Technical Requirements

#### 1. Provider Implementation
- Create `OpenAutoGLMProvider` class extending `BaseProvider`
- Add `OPEN_AUTOGLM` to `ProviderType` enum
- Implement all required BaseProvider methods:
- `initialize()`: Handle Open-AutoGLM startup and system checks
- `get_status()`: Analyze Open-AutoGLM output states
- `get_idle_pattern_for_log()`: Define idle state detection
- `extract_last_message_from_script()`: Extract execution results
- `exit_cli()`: Clean shutdown procedure
- `cleanup()`: Resource cleanup

#### 2. Configuration Support
- Support Open-AutoGLM configuration parameters:
- Model API endpoint and authentication
- ADB device management
- Virtual environment handling
- Project path configuration

#### 3. Status Management
- Define status patterns for Open-AutoGLM output:
- Processing states (thinking, executing actions)
- Completion states (task finished successfully)
- Error states (ADB failures, model API errors)
- Idle states (ready for next command)

#### 4. Integration Points
- Update `ProviderManager` to support OpenAutoGLM provider creation
- Ensure proper tmux session management
- Handle device-specific error scenarios

### 📁 Files to Modify
- `src/cli_agent_orchestrator/models/provider.py` - Add OPEN_AUTOGLM enum
- `src/cli_agent_orchestrator/providers/open_autoglm.py` - New provider implementation
- `src/cli_agent_orchestrator/providers/manager.py` - Add provider creation logic

### 🔍 Acceptance Criteria

#### Core Functionality
- [ ] Successfully create and initialize OpenAutoGLM provider
- [ ] Properly detect and handle Open-AutoGLM execution states
- [ ] Extract execution results and thinking processes
- [ ] Handle device connection and ADB errors gracefully

#### Integration
- [ ] Provider works with CAO's session management
- [ ] Compatible with existing agent profile system
- [ ] Proper resource cleanup on provider termination

#### Testing
- [ ] Unit tests for provider implementation
- [ ] Integration tests with actual Open-AutoGLM setup
- [ ] Error handling validation

### 🎯 Use Cases
1. **Mobile App Testing**: Automated testing of Android applications through natural language
2. **Content Creation**: Automated social media posting and content generation
3. **Device Management**: Remote device configuration and maintenance
4. **Workflow Automation**: Cross-platform automation including mobile devices

### 📚 Additional Context
Open-AutoGLM requires:
- Python 3.10+ environment
- ADB (Android Debug Bridge) tools
- Connected Android device/emulator with USB debugging
- AutoGLM model service (local deployment or cloud API)
- ADB Keyboard installed on target device

### 🔗 Related Resources
- [Open-AutoGLM Repository](https://github.com/zai-org/Open-AutoGLM)
- [Base Provider Interface](https://github.com/awslabs/cli-agent-orchestrator/blob/main/src/cli_agent_orchestrator/providers/base.py)

---
**Priority**: Medium
**Complexity**: Medium
**Estimated Effort**: 2-3 days

Start by reading src/cli_agent_orchestrator/models/provider.py, the BaseProvider interface in src/cli_agent_orchestrator/providers/base.py, and existing provider implementations. Then inspect src/cli_agent_orchestrator/providers/manager.py for provider creation and session integration. Done means the provider initializes, reports states, extracts results, handles device and API errors, and has unit and integration coverage.

Written by the indexing model from the issue text.